List available proposal templates (e.g. 'default', 'rfp', 'sow'). Call this before generate_proposal if you're unsure which template_id to use.

Returns the fixed list and order of sections every proposal MUST contain.

Call this first. Draft all sections from the client brief and tool results, then make one generate_proposal call. Prefer decision-ready, client-specific content over generic marketing language; do not invent facts, pricing, timelines, certifications, or customer commitments.

Returns a condensed summary of the company's services, capabilities and differentiators, to be used for writing the Executive Summary and Understanding sections.

Look up quote-ready manpower rates for the verified client country. Args: country: The proposed company's verified country (e.g. "India" or "United Kingdom"). Country aliases such as UK are resolved safely; this tool never uses an ambiguous substring match. roles: optional list of role names to filter to (e.g. ["Cloud Architect", "Senior Engineer"]). Omit to get all roles for that country. level: optional exact seniority filter, for example "Junior", "Mid Senior", or "Senior". Returns compact JSON with the selected country sheet/fallback metadata and the exact quote rows. If no country sheet exists, the Constants sheet is used automatically and clearly identified as USD day-rate fallback.

Returns which countries/sheets exist in the rate card, in case the exact country name needs to be confirmed before calling get_rate_card.

Preview the rate-card selection for a verified client country before creating a proposal. This returns the exact sheet that will be used, or a clearly marked Constants/USD fallback if the country has no dedicated tab.

Pass the client's country as supplied in the brief or confirmed by trusted company research. A company name alone is intentionally not guessed: that could quote the wrong legal entity or geography.

STAGE 1: Create a project-specific rate card from the master rate card.

This tool MUST be called BEFORE generate_proposal. It:

1. Reads the master/company rate card for the specified country

2. Analyzes the project requirements and required roles

3. Creates a new 5-sheet workbook (Rate Card, Effort Model, Milestones, Retainer, Assumptions)

4. Validates the workbook for internal consistency

5. Saves it locally and uploads to the Output Drive folder

Args: client_name: Client company name (e.g., "ABC Company") project_name: Project name (e.g., "Cloud Transformation") country: Project country (e.g., "Nepal", "United Kingdom") project_scope: Brief description of project scope and requirements timeline_months: Project duration in months budget: Budget indication (e.g., "NPR 25,00,000" or "GBP 150,000") required_roles: List of dicts with keys: role, discipline, seniority, estimated_days Example: [ {"role": "Backend Engineer", "discipline": "Backend Developer", "seniority": "Senior", "estimated_days": 60}, {"role": "Frontend Engineer", "discipline": "Frontend Developer", "seniority": "Mid Senior", "estimated_days": 45}, ]

Returns JSON with the local path, Drive link, and validation status. The generated rate card becomes the authoritative source for all proposal costing.

STAGE 1b: Validate and reload a project rate card from disk.

This tool reads the generated .xlsx file back into memory to ensure Stage 2 (proposal generation) uses the actual generated workbook as the source of truth, not the in-memory master rate card data.

Args: local_path: Path to the generated project rate card .xlsx file

Returns the parsed ProjectRateCardData as JSON.

Generates the final branded proposal .docx and uploads it to the Output Drive folder. This is the LAST step, called once per proposal.

proposal_json must be a JSON string matching this shape: { "title": "Cloud Modernisation Proposal", "client_name": "XYZ Bank", "country": "India", "template_id": "default", "rate_card_path": "/path/to/project_rate_card.xlsx", // optional: path to project-specific rate card "sections": [ { "section_id": "executive_summary", // must match one of get_mandatory_sections() ids "blocks": [ {"type": "paragraph", "text": "..."}, {"type": "bullets", "items": ["...", "..."]}, {"type": "sub_heading", "text": "..."}, {"type": "table", "headers": ["Role","Rate"], "rows": [["Cloud Architect","..."]]}, {"type": "bar_chart", "title": "...", "categories": ["Q1","Q2"], "values": [3,5], "y_label": "FTEs"}, {"type": "pie_chart", "title": "...", "labels": ["Cloud","Security"], "values": [60,40]}, {"type": "gantt_chart", "title": "Engagement Timeline", "tasks": [{"name":"Discovery","start":"2026-08-01","duration_days":14}]}, {"type": "workflow_diagram", "title": "Illustrative Digital-Service Workflow", "workflow_steps": [ {"label":"Users", "detail":"Submit secure requests"}, {"label":"AWS WAF + ALB", "detail":"Protect and route traffic"}, {"label":"Amazon EC2", "detail":"Run application services"}, {"label":"Amazon RDS", "detail":"Store transactional data"}, {"label":"CloudWatch", "detail":"Monitor and alert"} ]} ] }, ... one entry for EACH of the 9 mandatory section ids ... ] }

Authoring standard (important): write as a senior pre-sales consultant. Make every point specific to the supplied client brief and verified tool data. Use concise, complete prose: usually one 50-90 word paragraph per idea and 3-5 parallel bullets where bullets are more scannable. Use tables for comparisons, pricing, roles, assumptions, and milestones; use charts only when the supplied numbers make a decision easier. Avoid filler, repeated claims, unsupported superlatives, and invented numbers. Preserve uncertainty as an assumption or validation item. Return only valid JSON in the required shape—no Markdown, commentary, or duplicated narrative.

The required Illustrative Technical Workflow section must be immediately before Conclusion. Include one workflow_diagram plus, where helpful, one short framing paragraph. Make the components specific to the client domain and selected platform; only use named services (for example Amazon EC2) when they are in scope or clearly labelled illustrative. Keep the diagram to its end-to-end path, rather than a detailed design.

All 9 mandatory sections (see get_mandatory_sections) must be present or this call will fail with a clear error listing what's missing. This compact structure produces a high-quality proposal without wasting output tokens. Returns the Drive link to the finished document.