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
Scored across 6 tools
get_profile and get_user_profile overlap heavily: both return display name and email, and differ only by workspace/account vs organization/role context. get_card_state is explicitly internal-only, which is clear but still an unusual agent-facing tool that adds surface complexity.
All tools use consistent snake_case verb_noun naming: create_proposal, get_card_state, get_profile, get_user_profile, list_documents, set_website. The pattern is predictable and readable.
Six tools is well-scoped for a focused proposal-creation assistant. Each tool maps to a distinct setup or document workflow step, with no unnecessary bloat.
The surface supports creating and listing proposals plus workspace setup/profile lookup, but lacks direct get, update, or delete operations for documents. Agents cannot read proposal bodies or modify existing proposals through the tool set, only via an external builder URL.
Create a new proposal from plain Markdown content. Provide the proposal body as standard Markdown text (headings, paragraphs, lists, tables); the platform converts it into builder pages. Do not send JSON, HTML, or pre-structured page objects. Call set_website first, before drafting. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | The title of the proposal | |
| cardId | No | Sent only by the in-chat website card. Never set it yourself. | |
| markdown | Yes | The proposal body as plain Markdown text only (## headings, paragraphs, - lists, | tables |). 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. | |
| websitePromptResume | No | Continuation token sent only by the in-chat website card. Never set it yourself. |
| Name | Required | Description |
|---|---|---|
| url | No | |
| title | Yes | |
| status | Yes | |
| proposalId | No | |
| renderType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and non-destructive, so the write nature is covered. The description adds genuinely new behavior: Markdown-to-builder-page conversion, the in-chat website card fallback, and the fact that websiteUrl triggers brand/content extraction. It does not cover permissions or failure modes, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then input constraint, then prerequisite, then edge cases. Every sentence carries operational information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, full annotation coverage, and 100% schema description coverage, the description's job is workflow and edge cases, which it delivers: prerequisite ordering, no-website card behavior, and user-supplied URL handling. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description earns above it: it explains the markdown format in prose, warns against JSON/HTML, and adds a selection rule for websiteUrl ('Use their own site, not a client's'). The cardId/websitePromptResume internals are left to the schema, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a new proposal from plain Markdown content') and immediately constrains the input format, distinguishing it from any structured-page creator. The reference to set_website as the prerequisite step makes it tellable apart from siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit ordering rule ('Call set_website first, before drafting') plus a conditional fallback path when no website exists, and instructs what to do when the user supplies their own site. This is real when-to-use guidance tied to a named sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Used only by the Proposal.biz card to restore its state after a chat reload. Never call this yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| cardId | Yes |
| Name | Required | Description |
|---|---|---|
| url | No | |
| title | No | |
| status | Yes | |
| proposalId | No | |
| renderType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and non-destructive, so safety is covered. The description adds genuinely new behavioral context — that this is an internal, UI-driven call rather than an agent-facing one — which is exactly the kind of information annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, and the critical constraint ('never call this yourself') is placed where it cannot be missed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 the description gives the one piece of context an agent actually needs — that it should not call this tool. Little else is required for a single-parameter internal endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description would need to explain cardId, and it does not. However, there is only one required parameter and its name plus uuid format make its meaning largely self-evident without further prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific function — restoring the Proposal.biz card's state after a chat reload — which is concrete and distinguishable from siblings like create_proposal or get_profile. It stops short of describing what 'state' means or what is returned, but an agent can tell what the tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
This is the rare case of an explicit exclusion: 'Used only by the Proposal.biz card' and 'Never call this yourself.' No ambiguity remains about whether the agent should invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the connected Proposal.Biz profile: a stable account id, display name, email, and workspace name
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | No | |
| No | ||
| nickname | No |
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.
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.
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.
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.
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.
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.
Get the authenticated user's display name, email, selected organization name, and role
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| user | Yes | |
| organizationRole | Yes | |
| activeOrganization | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful scoping fact that this returns the *authenticated* user rather than an arbitrary one, but says nothing about auth failure behavior or caching. An output schema exists, so field details are not required here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, naming verb, resource, and scope immediately. The enumerated field list is slightly redundant with the existing output schema but costs little and adds precision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter read tool with full annotation coverage and an output schema, the description supplies everything essential: identity of the subject and what is returned. The only real omission is differentiation from the similar-sounding get_profile sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case per the rubric. There is nothing for the description to clarify beyond the fact that it is parameterless and implicitly scoped to the caller.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (authenticated user's profile) and enumerates the exact fields returned (display name, email, organization name, role). However, it does not distinguish itself from the sibling get_profile, leaving the agent to guess which profile tool applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no prerequisites, and no mention of alternatives such as get_profile, even though that sibling plausibly overlaps in intent. The scope hint 'authenticated user's' is the only implicit usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| hasMore | Yes | |
| documents | Yes |
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.
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.
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.
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.
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.
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.
Check or set the user's own website for the workspace. Always call this with no arguments FIRST for every new document, before asking discovery questions or drafting, even if the user skipped it for an earlier document in this chat. 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; say one short line pointing to the card and wait for the user. If the user says they added or skipped it in the card, it is already saved: do not call this again. If the user types a website in chat, call this with websiteUrl; if they skip or decline, call this with skip: true. 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.
| 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. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds the state machine (has_website, started, skipped, not_needed), the side effect that a websiteUrl 'starts background extraction', the card-driven UI flow, and the explicit no-op condition — behavioral detail far 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long for a tool description, but the core purpose is front-loaded and each sentence encodes a distinct branch or guard condition rather than filler. Minor redundancy between the 'do not call again' and status-gating sentences keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, yet the description still enumerates the statuses an agent must branch on. For a zero-required-parameter orchestration tool with a card interaction, the description supplies everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: skip:true is tied to an explicit user decline and websiteUrl to a user-typed site, while cardId is acknowledged as system-only ('never set it yourself'). This clarifies usage conditions the schema descriptions state only tersely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific dual-mode verb (check or set) on a specific resource (the user's own website for the workspace), and explicitly distinguishes 'the user's own site, never a client's site'. An agent can tell it apart from get_profile or list_documents without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit ordering ('always call with no arguments FIRST for every new document'), when NOT to call ('do not call this again' after card completion), and per-branch routing for each user response (typed URL, skip, card interaction). Nothing about invocation timing 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_proposalget_card_stateget_profileget_user_profilelist_documentsset_website
Add one secure layer between your agents and this server.