Skip to main content
Glama
Sign In
lightbulb-mcp

lightbulb-mcp

by RPasquale
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

company_bootstrap

Generate a company setup bundle from organisation, connectors, and book data. Propose, accept, or show the bundle to bootstrap a project's company.

Instructions

Zero to running for one project. propose: from the ledger's organisation read ({provenance, payload}), the project's connectors and, when recorded, a books snapshot, seal a bundle proposal: the company ref, the archetype and the evidence it was chosen on, the compiled bundle with the ledger-first plans added, the account roles suggested by name, every assumption, and what each connector unlocks or still needs. accept: verify a proposal and keep its bundle in the project, so every other company tool can be called with an empty bundle_json. show: the stored bundle's company, currency, archetype and plans. payload_json for propose takes organisation, connectors, books, archetype, business_model, company_ref, actor_ref, project_ref; for accept takes proposal. Nothing reads or writes a provider.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>"
    },
    "name": "company_bootstrap"
  }
}

Input Schema

NameRequiredDescriptionDefault
nowNo
operationNoshow
project_idYes
payload_jsonNo{}

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.4

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description must carry the full burden. It does disclose meaningful behavior: propose reads from the ledger and produces a proposal, accept verifies and stores the bundle, and show displays the bundle. It also adds a valuable constraint: 'Nothing reads or writes a provider.' Nevertheless, it doesn't clarify whether propose persists anything or whether any operation can fail, which would be useful transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sprawling paragraph that mixes three operations and parameter details, making it hard to scan. Although it does use the markers 'propose:', 'accept:', 'show:', these are embedded in long sentences. It could be dramatically shortened and structured with bullet points or a table. The lack of structure hurts its usability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (three modes) and the absence of schema descriptions, the description provides the essential flow and payload contents, which is substantial. Since an output schema exists, return values needn't be covered. However, it omits a clear list of allowed operation values, any explanation of 'now', and error/prerequisite context, leaving the agent to infer crucial details. Incomplete for this level of complexity.

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?

The schema has 4 parameters with 0% coverage, so the description must compensate. It does explain that payload_json takes specific fields for propose (organisation, connectors, books, archetype, business_model, etc.) and for accept (proposal), adding meaning beyond the raw schema. However, it does not describe 'now', 'operation' is only implied via the prose (not enumerated), and 'project_id' is not explicitly defined as an identifier context. Partial compensation with gaps.

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 identifies the tool as a company bootstrap operation with three distinct verbs (propose, accept, show) and a defined scope ('Zero to running for one project'). It explains what each mode does in specific terms, which helps distinguish it from other company_* tools. However, the purpose is conveyed through a dense run-on paragraph rather than a crisp single-verb summary, and there is no explicit comparison to sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by explaining each operation (propose, accept, show) and notes a key consequence: after accept, other tools can be called with an empty bundle_json. This gives some contextual guidance. However, it never explicitly states when to prefer company_bootstrap over alternatives like company_launch or company_bring_up, nor does it mention exclusions or prerequisites.

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

Deploy Server

Other Tools