A
licenseNot graded
qualityB
maintenancePerplexity for social: ask what competitors are running across social and get answers grounded in real ad and creative data, not guesses.
2
Apache 2.0
Proposal.biz
Server Details
Proposal.Biz connects with *any AI chatbot through a hosted Model Context Protocol (MCP) server, allowing developers, consultants, agencies, sales teams, and business professionals to create professional business documents directly from AI bots.
With the Proposal.Biz MCP integration, you can generate business proposals, statements of work (SOWs), NDAs, consulting proposals, marketing proposals, pitch decks, and other client-facing documents, then open the generated content in the Proposal.Biz b
Ownership verified
- Status
- Healthy
- Uptime
- 99.1% over 21 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.1/5.0
Scored across 7 tools
Disambiguation4/5
Most tools target clearly distinct actions (initialize_chat, create_proposal, list_documents, get_profile), but the website pair check_website/set_website have heavily cross-referencing descriptions that describe the same card/status flow, which could blur which one to call. get_card_state is explicitly labeled internal-only, which helps.
Naming Consistency5/5
All seven tools use a consistent snake_case verb_noun pattern (check_website, create_proposal, set_website, get_card_state, get_profile, initialize_chat, list_documents). The convention is predictable throughout.
Tool Count5/5
Seven tools is well-scoped for a proposal/document creation assistant, covering chat initialization, profile, website state, document listing, proposal creation, and card state. Each tool appears to earn its place.
Completeness3/5
The surface supports creating and listing documents but offers no get_document, update_proposal, or delete operation, and list_documents explicitly omits document body. This leaves notable lifecycle gaps for editing or retrieving existing proposals.
Available Tools
7 toolscheck_websiteARead-onlyInspect
Check whether the workspace has the user's own website. Call after initialize_chat, before drafting each new document. Continue with the document for every status. If status is missing, do not ask for the website in chat and do not call set_website: when you call create_proposal, its card lets the user add their website or skip, and the card creates the document.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| message | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds workflow-level behavior: what to do for every status value and how the missing case is handled downstream by create_proposal. It does not detail the status values themselves, but the output schema exists to carry that.
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?
Front-loaded with purpose and timing, and every sentence carries routing logic. Slightly dense and the clause 'Continue with the document for every status' is a bit terse, costing it the top mark.
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?
Covers ordering, the missing-status case, and forbidden alternatives, which is what an agent needs to call it correctly. Return values are covered by the existing output schema, so the description need not restate them.
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?
Zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond confirming the call is argument-free. No over- or under-specification.
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+resource: checks whether the workspace holds the user's own website, which is clearly distinct from set_website (writes it) and get_profile. An agent can identify the tool's job immediately.
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 explicit invocation ordering (after initialize_chat, before drafting each new document) and explicit exclusions: if status is missing, do not ask for the website in chat and do not call set_website. Names the alternative path (create_proposal's card) too.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_proposalAInspect
Create a new proposal from plain Markdown content. Provide the approved content as standard Markdown text (headings, paragraphs, lists, tables) and a short brief; the platform designs the pages, layout, images, and charts. Do not send JSON, HTML, page markers, or pre-structured page objects. Call check_website before drafting, after initialize_chat has been called in this conversation. If the workspace still has no website, the result shows a card where the user can add one or skip; the card then creates the document. If the user shares their own website in chat, pass it as websiteUrl. If the user asked for specific colors, fonts, or a look for this document, pass them as theme; otherwise omit it and the workspace theme is used.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | A plain-text brief for the designer, who sees only the Markdown and this brief, never the chat. The Markdown carries the facts; the brief carries what the conversation established that changes how the document should be built: its purpose, who reads it and what they will check, the tone, the length or page count the user asked for, anything they asked to see in their own words (for example a chart or side-by-side options), and what must stay exact, separate, or out. Its length follows the document, from a few sentences for a quote to about 300 words for a long contract. Do not summarise the content. | |
| theme | No | Only when the user asked for specific colors, fonts, or a look for this document. Exact hex codes and font names they gave go in the color and font fields as sent. If they described colors or a feel in words ("dark blue", "earthy and premium") without hex codes, design the palette yourself, set designed to true, and name it: a deep, slightly muted primary that reads clearly on cardBackground, an optional secondary, a white or faintly tinted cardBackground (dark only when they ask for dark mode, or for a deck), and fonts that carry the feel. Always include imageStylePrompt with the theme: palette in words, lighting, and mood. A color word means that hue as the accent, not a dark page. Omit theme when they asked for nothing visual ("professional", "clean"). The platform derives every role you leave out. Never invent colors the user did not ask for. | |
| title | Yes | The title of the proposal | |
| cardId | No | Sent only by the in-chat website card. Never set it yourself. | |
| currency | No | Optional. The ISO 4217 code (INR, EUR, AED, GBP, USD) of the currency the prices in this document are in, as the user stated them or the content shows. Pricing tables print this currency instead of the workspace default. Omit it when the document has no prices or the currency is not clear. | |
| markdown | Yes | The approved content as plain Markdown text only (## headings, paragraphs, - lists, | tables |). It carries the facts and wording; the platform decides pages and layout. Must NOT be JSON or a structured page object. | |
| renderType | No | Render type (default: document) | |
| websiteUrl | No | The user's website. Starts workspace brand and content extraction, then creates the proposal. Use their own site, not a client's. | |
| headerFooter | No | Optional. Text or the page number repeated on every page except the cover. It helps when readers cite or trace pages, as in contracts, SOWs, RFP responses, and longer formal documents, and it clutters short, persuasive, or screen-first documents such as quotes, presentations, and webpages. Decide from the document type and length; omit it when unsure. A footer usually serves best: page_number at bottom-right plus at most one short text (about 50 characters) at bottom-left, such as a confidentiality mark or the document reference. | |
| websitePromptResume | No | Continuation token sent only by the in-chat website card. Never set it yourself. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| url | No | |
| theme | No | The custom theme that was applied, with any adjustments made to it. |
| title | Yes | |
| status | Yes | |
| proposalId | No | |
| renderType | Yes |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly=false, destructive=false, openWorld=true; the description goes well beyond that by disclosing the no-website fallback card flow, that cardId/websitePromptResume are card-authored only, and that omitting theme falls back to the workspace theme. These are the side effects and control-flow an agent needs before invoking 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?
Front-loaded with the core action before the procedural details, and the body is dense with actionable guidance rather than filler. It does, however, restate the Markdown-format prohibition (no JSON/HTML/page markers) that the markdown parameter description already states, which is mild redundancy in an otherwise tight block.
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?
An output schema exists, so return values need not be explained, and with 10 parameters all documented at 100% coverage the description's remaining job is workflow context, which it fully covers: prerequisites, the fallback card path, and theme derivation rules. Nothing an agent needs to call this correctly is missing.
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 baseline is 3, but the description adds genuine meaning: it tells the agent when to supply theme versus omit it, to pass the user's own site as websiteUrl, and to never set cardId/websitePromptResume itself. It stays thin on a few fields (currency, headerFooter, renderType) that the schema already handles well, so it is not a full 5.
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?
Opens with a specific verb and resource ("Create a new proposal from plain Markdown content") and immediately clarifies the input contract (Markdown + brief) and what the platform does with it (pages, layout, images, charts). This is distinguishable from siblings like list_documents or set_website 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?
Explicit sequencing: call check_website before drafting, after initialize_chat. Explicit routing for websiteUrl (only the user's own site, not a client's) and an explicit when-to/when-not for theme ("otherwise omit it and the workspace theme is used"). Nothing material 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.
get_card_stateARead-onlyInspect
Used only by the Proposal.biz card to restore its state after a chat reload. Never call this yourself.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| url | No | |
| title | No | |
| status | Yes | |
| proposalId | No | |
| renderType | No | |
| documentReady | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, non-destructive, closed-world safety. The description adds important caller-restriction context: it is intended solely for the Proposal.biz card and should never be called directly by an agent. It doesn't describe the return format, but the output schema covers that.
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?
Two short, front-loaded sentences with zero waste. The key instruction ('Never call this yourself') is placed last for emphasis, which is appropriate.
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 an internal tool with an output schema and clear annotations, the description provides exactly what an agent needs: a reason to avoid calling it and sufficient context to understand its role. Parameter details are not critical since the tool should not be selected by the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single required parameter 'cardId' is not mentioned in the description. While the name and UUID format make it self-evident, the description does nothing to compensate for the missing schema description. The rule says low coverage requires description to compensate, which it does not.
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 states the tool's purpose: it restores the Proposal.biz card's state after a chat reload. It distinguishes from siblings by specifying the sole caller and the UI context. It doesn't explicitly state the return value (though an output schema exists), but the verb 'restore' implies retrieving state.
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?
Explicitly gives when to use ('only by the Proposal.biz card to restore its state after a chat reload') and when not to use ('Never call this yourself'). This is a definitive exclusion for general agents, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_profileARead-onlyInspect
Get the connected Proposal.Biz profile: a stable account id, display name, email, and workspace name
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | No | |
| No | ||
| nickname | No |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds only the set of returned fields, which duplicates the output schema and gives no extra behavioral context such as auth requirements or identity-scoping behavior.
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?
A single compact sentence, front-loaded with the action and resource and then the payload. Every clause earns its place with no 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 zero-parameter read tool with a full output schema and explicit safe-read annotations, the description covers what is needed. The one gap is the unresolved overlap with get_user_profile, which the description does not address.
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?
The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond the field list it already provides.
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 ('Get the connected Proposal.Biz profile') and enumerates the fields returned (account id, display name, email, workspace name). It is clear on its own, but it never distinguishes itself from the sibling get_user_profile, leaving the agent to guess which profile is which.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative, get_user_profile. The word 'connected' implies an account context but is never explained or contrasted with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
initialize_chatInitialize chatARead-onlyInspect
Initialize this Proposal.biz chat from the user's first message. Call exactly once at the start of a new conversation, before other tools. Do not call again in this chat, and do not call when starting another document in the same chat. Pass a short paraphrase of the first ask, with no names, emails, or URLs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | A short paraphrase of what the user is trying to do in this chat, from their first message. No names, emails, URLs, or quoted client content. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false; the description is consistent with a non-destructive session-setup call and adds real behavioral context beyond them: one-shot call semantics, ordering relative to other tools, and no-repeat constraints. It does not describe failure behavior if called twice, which is the only notable gap.
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?
Three tight sentences, zero waste, with the core purpose front-loaded and the call-once constraints immediately after. Every sentence carries a distinct instruction.
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 single-parameter session-initialization tool with a declared output schema, the description covers purpose, timing, idempotency, and content constraints. Nothing an agent needs in order to invoke it correctly is missing.
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 coverage is 100% and the single 'summary' parameter's description already states the paraphrase plus no names/emails/URLs constraint, which the description essentially repeats. Baseline 3 is appropriate since the schema does the heavy lifting, with the description only reinforcing the privacy rule.
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 ('Initialize this Proposal.biz chat') and scopes it to the user's first message. It is clearly distinguishable from siblings like create_proposal, list_documents, or get_profile, which operate on documents or profiles rather than chat session state.
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?
Explicit invocation rules: call exactly once at the start of a new conversation, before other tools, never again in the same chat, and not when starting another document in the same chat. Both the when and the when-not conditions are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_documentsARead-onlyInspect
List documents in the connected workspace that this user can open. Owners see every non-deleted document, including those in folders. Members see documents they created or collaborate on. Returns id, title, status, render type, last updated time, and a builder edit URL. Optional title search, status, and render type filters. Does not return document body.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of documents to return (default 20, max 50) | |
| query | No | Filter by title (case-insensitive contains) | |
| offset | No | Number of documents to skip (default 0) | |
| status | No | Filter by document status | |
| renderType | No | Filter by render type |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| hasMore | Yes | |
| documents | Yes |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description goes further by disclosing permission-based scoping (owners see every non-deleted document, members only see created/collaborated documents), the returned field set, and explicitly that the document body is excluded, adding meaningful behavioral context beyond the annotations.
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?
It is front-loaded with the core list operation and scope, then layers in visibility rules, return fields, and filters. Every sentence contributes relevant information without redundancy or filler.
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?
Given five optional parameters, an output schema, and existing annotations, the description supplies the remaining context an agent needs: who sees what, what fields come back, what is omitted, and what filters exist. Nothing required for correct invocation appears to be missing.
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%, with all five parameters documented in the schema, including defaults, max, enum values, and case-insensitive matching. The description only restates that title, status, and render type filters are optional, so it adds little beyond the structured schema; baseline 3 applies.
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 opens with a specific verb and resource ('List documents') plus the scoping context ('in the connected workspace that this user can open'). It is immediately distinguishable from the unrelated siblings (create_proposal, get_profile, set_website), none of which list documents.
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?
The description clearly explains the visibility model for owners versus members and enumerates the optional filters, so an agent knows what it will get back and how to narrow results. It does not, however, state any when-not-to-use condition or name an alternative tool, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_websiteAInspect
Save the user's own website for the workspace. Call this only when the user types their website in chat (pass websiteUrl) or declines it in chat (pass skip: true); never call it just to check, use check_website for that. If status is missing, a card asks the user for their website (logo, colors, company details, and reusable service descriptions come from it) with a Skip option; let the card speak for itself and wait without sending a separate chat reply. If the user says they added or skipped it in the card, it is already saved: do not call this again. Proceed with the document after status is has_website, started, skipped, or not_needed. Use the user's own site, never a client's site.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Set true only when the user explicitly declines to share a website. | |
| cardId | No | Sent only by the in-chat website card. Never set it yourself. | |
| websiteUrl | No | The user's website, e.g. https://acme.com. Starts background extraction. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| message | Yes |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), it discloses non-obvious workflow behavior: URL input starts background extraction, a card solicits the website when status is missing, no separate chat reply should be sent while waiting, and skip/added actions are already persisted. These are substantive side-effect and timing disclosures annotations cannot carry.
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 purpose is front-loaded in the first sentence and subsequent sentences are operationally load-bearing (exclusions, card flow, status gating). It is a dense wall of text, but nearly every clause earns its place; only minor consolidation is possible.
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?
An output schema exists, so return values need not be explained. Given the conditional/stateful nature of this tool, the description covers triggers, exclusions, duplicate-call protection, waiting behavior, and the ownership rule, which is everything an agent needs to call it correctly.
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: it maps the conditional usage of websiteUrl (only when the user types it in chat) and skip (only on explicit decline), and warns that cardId is never set by the caller. This goes beyond the schema's own field descriptions without contradicting them.
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+resource ('Save the user's own website for the workspace') and immediately scopes it against siblings by naming check_website as the tool for verification. It further disambiguates ownership ('Use the user's own site, never a client's site'), so an agent can distinguish it from check_website and the document/proposal siblings 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 explicit triggering conditions (user types the website -> websiteUrl; user declines -> skip: true), explicit exclusions ('never call it just to check'), and duplicate-call prevention ('If the user says they added or skipped it in the card, it is already saved: do not call this again'). It also specifies the required pre-state (status must be has_website, started, skipped, or not_needed) before proceeding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
create_proposal1 field changed- added
Input schema / properties / currencyAdded value: +{ + "description": "Optional. The ISO 4217 code (INR, EUR, AED, GBP, USD) of the currency the prices in this document are in, as the user stated them or the content shows. Pricing tables print this currency instead of the workspace default. Omit it when the document has no prices or the currency is not clear.", + "type": [ + "string", + "null" + ] +}
1 tool update
- Changed
create_proposal2 fields changed- changed
Input schema / properties / theme / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "body": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Paragraph text color. Must read clearly on cardBackground." - }, - "bodyFont": { - "anyOf": [ - { - "enum": [ - "arial", - "times-new-roman", - "georgia", - "helvetica", - "roboto", - "open-sans", - "montserrat", - "inter", - "poppins", - "lato", - "oswald", - "raleway", - "nunito", - "nunito-sans", - "rubik", - "ubuntu", - "playfair-display", - "merriweather", - "roboto-slab", - "work-sans", - "dm-sans", - "lora", - "jost", - "manrope", - "quicksand", - "fira-sans", - "barlow", - "mulish", - "cabin", - "karla", - "source-sans-3", - "pt-sans", - "pt-serif", - "libre-baskerville", - "outfit", - "bebas-neue", - "sora", - "space-grotesk", - "lexend", - "plus-jakarta-sans", - "figtree", - "ibm-plex-sans", - "eb-garamond", - "bitter", - "crimson-text" - ], - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Body font id, the closest available match. Prefer a readable sans-serif." - }, - "button": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Button color. Leave out to use primary." - }, - "cardBackground": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "The page surface itself, where all text sits. If the user names only one background color, such as off-white, send it here. For a dark document, use a near-black tinted toward the accent hue, not flat #121212 or #000000." - }, - "designed": { - "description": "Set true when you chose these colors and fonts yourself from a look the user described in words, and they gave no hex codes or font names for them. They are then checked for readability and adjusted if needed. Leave out when the user gave exact values, which are used exactly.", - "type": [ - "boolean", - "null" - ] - }, - "heading": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Heading text color. Must read clearly on cardBackground." - }, - "headingFont": { - "anyOf": [ - { - "enum": [ - "arial", - "times-new-roman", - "georgia", - "helvetica", - "roboto", - "open-sans", - "montserrat", - "inter", - "poppins", - "lato", - "oswald", - "raleway", - "nunito", - "nunito-sans", - "rubik", - "ubuntu", - "playfair-display", - "merriweather", - "roboto-slab", - "work-sans", - "dm-sans", - "lora", - "jost", - "manrope", - "quicksand", - "fira-sans", - "barlow", - "mulish", - "cabin", - "karla", - "source-sans-3", - "pt-sans", - "pt-serif", - "libre-baskerville", - "outfit", - "bebas-neue", - "sora", - "space-grotesk", - "lexend", - "plus-jakarta-sans", - "figtree", - "ibm-plex-sans", - "eb-garamond", - "bitter", - "crimson-text" - ], - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Heading font id, the closest available match to the look asked for. Serif ids: times-new-roman, georgia, playfair-display, merriweather, roboto-slab, lora, pt-serif, libre-baskerville, eb-garamond, bitter, crimson-text; the rest are sans-serif." - }, - "headingWeight": { - "anyOf": [ - { - "maximum": 800, - "minimum": 500, - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "Heading weight, 500 to 800. Omit for bold (700)." - }, - "link": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Inline link color. Leave out to use primary." - }, - "name": { - "anyOf": [ - { - "maxLength": 60, - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Short theme name shown in the builder, such as \"Moss and champagne\"." - }, - "pageBackground": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "The canvas behind the document pages. Send it with cardBackground, in the same hue family and a shade deeper than the card (light or dark), never the same color and never pure black." - }, - "primary": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Main brand color, used for table headers, borders, dividers, icons, and highlights. The most recognizable brand color, not a neutral." - }, - "secondary": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Soft accent that fills callouts, stat boxes, and subtle blocks. Light colors work best, so a second brand color such as champagne or sand fits here. Leave out to derive it from primary." - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "body": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Paragraph text color. Must read clearly on cardBackground." + }, + "bodyFont": { + "anyOf": [ + { + "enum": [ + "arial", + "times-new-roman", + "georgia", + "helvetica", + "roboto", + "open-sans", + "montserrat", + "inter", + "poppins", + "lato", + "oswald", + "raleway", + "nunito", + "nunito-sans", + "rubik", + "ubuntu", + "playfair-display", + "merriweather", + "roboto-slab", + "work-sans", + "dm-sans", + "lora", + "jost", + "manrope", + "quicksand", + "fira-sans", + "barlow", + "mulish", + "cabin", + "karla", + "source-sans-3", + "pt-sans", + "pt-serif", + "libre-baskerville", + "outfit", + "bebas-neue", + "sora", + "space-grotesk", + "lexend", + "plus-jakarta-sans", + "figtree", + "ibm-plex-sans", + "eb-garamond", + "bitter", + "crimson-text" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Body font id, the closest available match. Prefer a readable sans-serif." + }, + "button": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Button color. Leave out to use primary." + }, + "cardBackground": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The page surface itself, where all text sits. If the user names only one background color, such as off-white, send it here. For a dark document, use a near-black tinted toward the accent hue, not flat #121212 or #000000." + }, + "designed": { + "description": "Set true when you chose these colors and fonts yourself from a look the user described in words, and they gave no hex codes or font names for them. They are then checked for readability and adjusted if needed. Leave out when the user gave exact values, which are used exactly.", + "type": [ + "boolean", + "null" + ] + }, + "heading": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Heading text color. Must read clearly on cardBackground." + }, + "headingFont": { + "anyOf": [ + { + "enum": [ + "arial", + "times-new-roman", + "georgia", + "helvetica", + "roboto", + "open-sans", + "montserrat", + "inter", + "poppins", + "lato", + "oswald", + "raleway", + "nunito", + "nunito-sans", + "rubik", + "ubuntu", + "playfair-display", + "merriweather", + "roboto-slab", + "work-sans", + "dm-sans", + "lora", + "jost", + "manrope", + "quicksand", + "fira-sans", + "barlow", + "mulish", + "cabin", + "karla", + "source-sans-3", + "pt-sans", + "pt-serif", + "libre-baskerville", + "outfit", + "bebas-neue", + "sora", + "space-grotesk", + "lexend", + "plus-jakarta-sans", + "figtree", + "ibm-plex-sans", + "eb-garamond", + "bitter", + "crimson-text" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Heading font id, the closest available match to the look asked for. Serif ids: times-new-roman, georgia, playfair-display, merriweather, roboto-slab, lora, pt-serif, libre-baskerville, eb-garamond, bitter, crimson-text; the rest are sans-serif." + }, + "headingWeight": { + "anyOf": [ + { + "maximum": 800, + "minimum": 500, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "Heading weight, 500 to 800. Omit for bold (700)." + }, + "imageStylePrompt": { + "anyOf": [ + { + "maxLength": 500, + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Always send this when you send theme. One or two sentences: the palette in words matching the colors, the lighting, and the mood. Translate a feel the user named (\"earthy and premium\") into those three. Example: \"Warm ivory and soft stone neutrals with muted moss accents. Soft natural window light, gentle shadows, generous negative space. Calm, refined mood.\" No hex codes, brand or company names, logos, or a medium (photography vs illustration vs 3D)." + }, + "link": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Inline link color. Leave out to use primary." + }, + "name": { + "anyOf": [ + { + "maxLength": 60, + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Short theme name shown in the builder, such as \"Moss and champagne\"." + }, + "pageBackground": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The canvas behind the document pages. Send it with cardBackground, in the same hue family and a shade deeper than the card (light or dark), never the same color and never pure black." + }, + "primary": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Main brand color, used for table headers, borders, dividers, icons, and highlights. The most recognizable brand color, not a neutral." + }, + "secondary": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Soft accent that fills callouts, stat boxes, and subtle blocks. Light colors work best, so a second brand color such as champagne or sand fits here. Leave out to derive it from primary." + } + }, + "type": "object" + }, + { + "type": "null" + } +] - changed
Input schema / properties / theme / descriptionPrevious value: -"Only when the user asked for specific colors, fonts, or a look for this document. Exact hex codes and font names they gave go in the color and font fields as sent. If they described colors or a feel in words (\"dark blue\", \"earthy and premium\") without hex codes, design the palette yourself, set designed to true, and name it: a deep, slightly muted primary that reads clearly on cardBackground, an optional secondary, a white or faintly tinted cardBackground (dark only when they ask for dark mode, or for a deck), and fonts that carry the feel. A color word means that hue as the accent, not a dark page. Omit theme when they asked for nothing visual (\"professional\", \"clean\"). The platform derives every role you leave out. Never invent colors the user did not ask for."New value: +"Only when the user asked for specific colors, fonts, or a look for this document. Exact hex codes and font names they gave go in the color and font fields as sent. If they described colors or a feel in words (\"dark blue\", \"earthy and premium\") without hex codes, design the palette yourself, set designed to true, and name it: a deep, slightly muted primary that reads clearly on cardBackground, an optional secondary, a white or faintly tinted cardBackground (dark only when they ask for dark mode, or for a deck), and fonts that carry the feel. Always include imageStylePrompt with the theme: palette in words, lighting, and mood. A color word means that hue as the accent, not a dark page. Omit theme when they asked for nothing visual (\"professional\", \"clean\"). The platform derives every role you leave out. Never invent colors the user did not ask for."
1 tool update
- Changed
create_proposal1 field changed- changed
Input schema / properties / theme / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "body": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Paragraph text color. Must read clearly on cardBackground." - }, - "bodyFont": { - "anyOf": [ - { - "enum": [ - "arial", - "times-new-roman", - "georgia", - "helvetica", - "roboto", - "open-sans", - "montserrat", - "inter", - "poppins", - "lato", - "oswald", - "raleway", - "nunito", - "nunito-sans", - "rubik", - "ubuntu", - "playfair-display", - "merriweather", - "roboto-slab", - "work-sans", - "dm-sans", - "lora", - "jost", - "manrope", - "quicksand", - "fira-sans", - "barlow", - "mulish", - "cabin", - "karla", - "source-sans-3", - "pt-sans", - "pt-serif", - "libre-baskerville", - "outfit", - "bebas-neue", - "sora", - "space-grotesk", - "lexend", - "plus-jakarta-sans", - "figtree", - "ibm-plex-sans", - "eb-garamond", - "bitter", - "crimson-text" - ], - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Body font id, the closest available match. Prefer a readable sans-serif." - }, - "button": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Button color. Leave out to use primary." - }, - "cardBackground": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "The page surface itself, where all text sits. If the user names only one background color, such as off-white, send it here." - }, - "designed": { - "description": "Set true when you chose these colors and fonts yourself from a look the user described in words, and they gave no hex codes or font names for them. They are then checked for readability and adjusted if needed. Leave out when the user gave exact values, which are used exactly.", - "type": [ - "boolean", - "null" - ] - }, - "heading": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Heading text color. Must read clearly on cardBackground." - }, - "headingFont": { - "anyOf": [ - { - "enum": [ - "arial", - "times-new-roman", - "georgia", - "helvetica", - "roboto", - "open-sans", - "montserrat", - "inter", - "poppins", - "lato", - "oswald", - "raleway", - "nunito", - "nunito-sans", - "rubik", - "ubuntu", - "playfair-display", - "merriweather", - "roboto-slab", - "work-sans", - "dm-sans", - "lora", - "jost", - "manrope", - "quicksand", - "fira-sans", - "barlow", - "mulish", - "cabin", - "karla", - "source-sans-3", - "pt-sans", - "pt-serif", - "libre-baskerville", - "outfit", - "bebas-neue", - "sora", - "space-grotesk", - "lexend", - "plus-jakarta-sans", - "figtree", - "ibm-plex-sans", - "eb-garamond", - "bitter", - "crimson-text" - ], - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Heading font id, the closest available match to the look asked for. Serif ids: times-new-roman, georgia, playfair-display, merriweather, roboto-slab, lora, pt-serif, libre-baskerville, eb-garamond, bitter, crimson-text; the rest are sans-serif." - }, - "headingWeight": { - "anyOf": [ - { - "maximum": 800, - "minimum": 500, - "type": "integer" - }, - { - "type": "null" - } - ], - "description": "Heading weight, 500 to 800. Omit for bold (700)." - }, - "link": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Inline link color. Leave out to use primary." - }, - "name": { - "anyOf": [ - { - "maxLength": 60, - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Short theme name shown in the builder, such as \"Moss and champagne\"." - }, - "pageBackground": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "The canvas behind the document pages." - }, - "primary": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Main brand color, used for table headers, borders, dividers, icons, and highlights. The most recognizable brand color, not a neutral." - }, - "secondary": { - "anyOf": [ - { - "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Soft accent that fills callouts, stat boxes, and subtle blocks. Light colors work best, so a second brand color such as champagne or sand fits here. Leave out to derive it from primary." - } - }, - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "body": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Paragraph text color. Must read clearly on cardBackground." + }, + "bodyFont": { + "anyOf": [ + { + "enum": [ + "arial", + "times-new-roman", + "georgia", + "helvetica", + "roboto", + "open-sans", + "montserrat", + "inter", + "poppins", + "lato", + "oswald", + "raleway", + "nunito", + "nunito-sans", + "rubik", + "ubuntu", + "playfair-display", + "merriweather", + "roboto-slab", + "work-sans", + "dm-sans", + "lora", + "jost", + "manrope", + "quicksand", + "fira-sans", + "barlow", + "mulish", + "cabin", + "karla", + "source-sans-3", + "pt-sans", + "pt-serif", + "libre-baskerville", + "outfit", + "bebas-neue", + "sora", + "space-grotesk", + "lexend", + "plus-jakarta-sans", + "figtree", + "ibm-plex-sans", + "eb-garamond", + "bitter", + "crimson-text" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Body font id, the closest available match. Prefer a readable sans-serif." + }, + "button": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Button color. Leave out to use primary." + }, + "cardBackground": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The page surface itself, where all text sits. If the user names only one background color, such as off-white, send it here. For a dark document, use a near-black tinted toward the accent hue, not flat #121212 or #000000." + }, + "designed": { + "description": "Set true when you chose these colors and fonts yourself from a look the user described in words, and they gave no hex codes or font names for them. They are then checked for readability and adjusted if needed. Leave out when the user gave exact values, which are used exactly.", + "type": [ + "boolean", + "null" + ] + }, + "heading": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Heading text color. Must read clearly on cardBackground." + }, + "headingFont": { + "anyOf": [ + { + "enum": [ + "arial", + "times-new-roman", + "georgia", + "helvetica", + "roboto", + "open-sans", + "montserrat", + "inter", + "poppins", + "lato", + "oswald", + "raleway", + "nunito", + "nunito-sans", + "rubik", + "ubuntu", + "playfair-display", + "merriweather", + "roboto-slab", + "work-sans", + "dm-sans", + "lora", + "jost", + "manrope", + "quicksand", + "fira-sans", + "barlow", + "mulish", + "cabin", + "karla", + "source-sans-3", + "pt-sans", + "pt-serif", + "libre-baskerville", + "outfit", + "bebas-neue", + "sora", + "space-grotesk", + "lexend", + "plus-jakarta-sans", + "figtree", + "ibm-plex-sans", + "eb-garamond", + "bitter", + "crimson-text" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Heading font id, the closest available match to the look asked for. Serif ids: times-new-roman, georgia, playfair-display, merriweather, roboto-slab, lora, pt-serif, libre-baskerville, eb-garamond, bitter, crimson-text; the rest are sans-serif." + }, + "headingWeight": { + "anyOf": [ + { + "maximum": 800, + "minimum": 500, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "Heading weight, 500 to 800. Omit for bold (700)." + }, + "link": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Inline link color. Leave out to use primary." + }, + "name": { + "anyOf": [ + { + "maxLength": 60, + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Short theme name shown in the builder, such as \"Moss and champagne\"." + }, + "pageBackground": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The canvas behind the document pages. Send it with cardBackground, in the same hue family and a shade deeper than the card (light or dark), never the same color and never pure black." + }, + "primary": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Main brand color, used for table headers, borders, dividers, icons, and highlights. The most recognizable brand color, not a neutral." + }, + "secondary": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Soft accent that fills callouts, stat boxes, and subtle blocks. Light colors work best, so a second brand color such as champagne or sand fits here. Leave out to derive it from primary." + } + }, + "type": "object" + }, + { + "type": "null" + } +]
1 tool update
- Changed
create_proposal2 fields changed- added
Input schema / properties / themeAdded value: +{ + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "body": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Paragraph text color. Must read clearly on cardBackground." + }, + "bodyFont": { + "anyOf": [ + { + "enum": [ + "arial", + "times-new-roman", + "georgia", + "helvetica", + "roboto", + "open-sans", + "montserrat", + "inter", + "poppins", + "lato", + "oswald", + "raleway", + "nunito", + "nunito-sans", + "rubik", + "ubuntu", + "playfair-display", + "merriweather", + "roboto-slab", + "work-sans", + "dm-sans", + "lora", + "jost", + "manrope", + "quicksand", + "fira-sans", + "barlow", + "mulish", + "cabin", + "karla", + "source-sans-3", + "pt-sans", + "pt-serif", + "libre-baskerville", + "outfit", + "bebas-neue", + "sora", + "space-grotesk", + "lexend", + "plus-jakarta-sans", + "figtree", + "ibm-plex-sans", + "eb-garamond", + "bitter", + "crimson-text" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Body font id, the closest available match. Prefer a readable sans-serif." + }, + "button": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Button color. Leave out to use primary." + }, + "cardBackground": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The page surface itself, where all text sits. If the user names only one background color, such as off-white, send it here." + }, + "designed": { + "description": "Set true when you chose these colors and fonts yourself from a look the user described in words, and they gave no hex codes or font names for them. They are then checked for readability and adjusted if needed. Leave out when the user gave exact values, which are used exactly.", + "type": [ + "boolean", + "null" + ] + }, + "heading": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Heading text color. Must read clearly on cardBackground." + }, + "headingFont": { + "anyOf": [ + { + "enum": [ + "arial", + "times-new-roman", + "georgia", + "helvetica", + "roboto", + "open-sans", + "montserrat", + "inter", + "poppins", + "lato", + "oswald", + "raleway", + "nunito", + "nunito-sans", + "rubik", + "ubuntu", + "playfair-display", + "merriweather", + "roboto-slab", + "work-sans", + "dm-sans", + "lora", + "jost", + "manrope", + "quicksand", + "fira-sans", + "barlow", + "mulish", + "cabin", + "karla", + "source-sans-3", + "pt-sans", + "pt-serif", + "libre-baskerville", + "outfit", + "bebas-neue", + "sora", + "space-grotesk", + "lexend", + "plus-jakarta-sans", + "figtree", + "ibm-plex-sans", + "eb-garamond", + "bitter", + "crimson-text" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Heading font id, the closest available match to the look asked for. Serif ids: times-new-roman, georgia, playfair-display, merriweather, roboto-slab, lora, pt-serif, libre-baskerville, eb-garamond, bitter, crimson-text; the rest are sans-serif." + }, + "headingWeight": { + "anyOf": [ + { + "maximum": 800, + "minimum": 500, + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "Heading weight, 500 to 800. Omit for bold (700)." + }, + "link": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Inline link color. Leave out to use primary." + }, + "name": { + "anyOf": [ + { + "maxLength": 60, + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Short theme name shown in the builder, such as \"Moss and champagne\"." + }, + "pageBackground": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The canvas behind the document pages." + }, + "primary": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Main brand color, used for table headers, borders, dividers, icons, and highlights. The most recognizable brand color, not a neutral." + }, + "secondary": { + "anyOf": [ + { + "pattern": "^#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Soft accent that fills callouts, stat boxes, and subtle blocks. Light colors work best, so a second brand color such as champagne or sand fits here. Leave out to derive it from primary." + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Only when the user asked for specific colors, fonts, or a look for this document. Exact hex codes and font names they gave go in the color and font fields as sent. If they described colors or a feel in words (\"dark blue\", \"earthy and premium\") without hex codes, design the palette yourself, set designed to true, and name it: a deep, slightly muted primary that reads clearly on cardBackground, an optional secondary, a white or faintly tinted cardBackground (dark only when they ask for dark mode, or for a deck), and fonts that carry the feel. A color word means that hue as the accent, not a dark page. Omit theme when they asked for nothing visual (\"professional\", \"clean\"). The platform derives every role you leave out. Never invent colors the user did not ask for." +} - added
Output schema / properties / themeAdded value: +{ + "additionalProperties": false, + "description": "The custom theme that was applied, with any adjustments made to it.", + "properties": { + "label": { + "type": "string" + }, + "notes": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "label", + "notes" + ], + "type": "object" +}
2 tool updates
- Added
initialize_chat - Removed
record_intent
2 tool updates
- Changed
create_proposal5 fields changed- changed
Input schema / properties / brief / descriptionPrevious value: -"A short note for the designer, under 200 words: the document type, who reads it and what they will check, the purpose, tone, requested length, and constraints from the conversation (for example \"use the figures exactly\", \"no invented warranties\"). Plain text, not Markdown content."New value: +"A plain-text brief for the designer, who sees only the Markdown and this brief, never the chat. The Markdown carries the facts; the brief carries what the conversation established that changes how the document should be built: its purpose, who reads it and what they will check, the tone, the length or page count the user asked for, anything they asked to see in their own words (for example a chart or side-by-side options), and what must stay exact, separate, or out. Its length follows the document, from a few sentences for a quote to about 300 words for a long contract. Do not summarise the content." - changed
Input schema / properties / brief / maxLengthPrevious value: -3000New value: +4000 - added
Input schema / properties / brief / minLengthAdded value: +1 - added
Input schema / properties / headerFooterAdded value: +{ + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "slot": { + "enum": [ + "top-left", + "top-center", + "top-right", + "bottom-left", + "bottom-center", + "bottom-right" + ], + "type": "string" + }, + "text": { + "description": "Short plain text; omit for page_number.", + "type": [ + "string", + "null" + ] + }, + "type": { + "enum": [ + "text", + "page_number" + ], + "type": "string" + } + }, + "required": [ + "slot", + "type" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "description": "Optional. Text or the page number repeated on every page except the cover. It helps when readers cite or trace pages, as in contracts, SOWs, RFP responses, and longer formal documents, and it clutters short, persuasive, or screen-first documents such as quotes, presentations, and webpages. Decide from the document type and length; omit it when unsure. A footer usually serves best: page_number at bottom-right plus at most one short text (about 50 characters) at bottom-left, such as a confidentiality mark or the document reference." +} - changed
Input schema / requiredPrevious value: -[ - "title", - "markdown" -]New value: +[ + "title", + "markdown", + "brief" +]
- Added
record_intent
1 tool update
- Removed
get_user_profile
2 tool updates
- Added
check_website - Changed
create_proposal2 fields changed- added
Input schema / properties / briefAdded value: +{ + "description": "A short note for the designer, under 200 words: the document type, who reads it and what they will check, the purpose, tone, requested length, and constraints from the conversation (for example \"use the figures exactly\", \"no invented warranties\"). Plain text, not Markdown content.", + "maxLength": 3000, + "type": "string" +} - changed
Input schema / properties / markdown / descriptionPrevious value: -"The proposal body as plain Markdown text only (## headings, paragraphs, - lists, | tables |). Must NOT be JSON or a structured page object."New value: +"The approved content as plain Markdown text only (## headings, paragraphs, - lists, | tables |). It carries the facts and wording; the platform decides pages and layout. Must NOT be JSON or a structured page object."
1 tool update
- Changed
get_card_state2 fields changed- added
Output schema / properties / documentReadyAdded value: +{ + "type": "boolean" +} - changed
Output schema / properties / status / enumPrevious value: -[ - "created", - "skipped", - "has_website", - "not_needed", - "missing" -]New value: +[ + "created", + "skipped", + "started", + "has_website", + "not_needed", + "missing" +]
6 tool updates
- First observed
create_proposal - First observed
get_card_state - First observed
get_profile - First observed
get_user_profile - First observed
list_documents - First observed
set_website
Publisher details
- Operator
- Proposal.biz · Publisher source
- Operator website
- https://www.proposal.biz/
- Vendor relationship
- Not applicable
- Documentation
- https://support.proposal.biz/
- Trust center
- Not applicable
- Restrictions
- Not applicable
Related MCP Servers
- AlicenseCqualityBmaintenanceCompetitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs119 npmMIT
- AlicenseAqualityCmaintenanceEnables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.164 npm1MIT
industrylens-mcpofficial
AlicenseNot gradedqualityBmaintenanceBrowse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.MIT
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd
Glama MCP Gateway
Add one secure layer between your agents and this server.