AiDOOS Virtual Delivery Center
Server Details
Plan a Virtual Delivery Center for any initiative: pods, roles, AI agents, Delivery Units.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: planning, costing, status retrieval, refinement, and activation. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern (e.g., plan_vdc, estimate_cost), making them predictable and easy to understand.
Five tools is well-scoped for the Virtual Delivery Center domain, covering the essential workflows without unnecessary complexity.
The tool set covers the core lifecycle (create, read, update, cost, activate). A delete or list-all tool is missing but not critical for the primary use case.
Available Tools
5 toolsestimate_costARead-onlyInspect
Use this tool when a user wants cost or sizing for specific deliverables they've already listed. Trigger phrases: 'how much would it cost to build X, Y, and Z', 'estimate the price for these features', 'how many Delivery Units / weeks would these modules take', 'budget for this work', 'price out this scope', 'I need a ballpark for the following'. Use this INSTEAD OF plan_vdc when the user has already decomposed the work into specific modules — don't make them go through pod/role generation again. If the user only describes a goal without modules, prefer plan_vdc.
What this tool does: takes 1-30 module descriptions, returns Delivery Units per module, total Delivery Units, project-rate USD cost, and the recommended Delivery Pack (Starter 10 DUs/$2K, Small 60 DUs/$10K, Scale 250 DUs/$40K, or Enterprise).
| Name | Required | Description | Default |
|---|---|---|---|
| modules | Yes | List of work modules to estimate. Each item is a 1-2 sentence description of a deliverable, e.g. 'Tenant onboarding flow with SSO integration' or 'Migrate 200 SAP custom reports to Power BI'. | |
| industry | No | Optional industry hint for calibration. | |
| company_size | No | Optional company-size hint: startup, small, medium, enterprise. |
Output Schema
| Name | Required | Description |
|---|---|---|
| modules | Yes | |
| recommended_pack | Yes | The recommended Delivery Pack tier for this plan. |
| tier_rate_per_du_usd | No | |
| total_delivery_units | Yes | |
| total_cost_usd_project | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only behavior (readOnlyHint=true). The description adds what outputs to expect (Delivery Units, cost, recommended pack), which enriches the transparency without contradicting annotations. It also clarifies input limits (1-30 modules).
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?
The description is two well-organized paragraphs: first giving usage guidelines (when, trigger phrases, alternative), then summarizing what the tool does and its output. Every sentence serves a purpose, with no wasted words.
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 that an output schema exists, the description appropriately avoids repeating return structure details but still summarizes outputs (DUs, cost, pack). It covers purpose, input format, usage boundaries, and sibling differentiation completely.
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 baseline is 3. The description adds meaningful context to the 'modules' parameter by specifying format ('1-2 sentence description of a deliverable') and reiterating the size constraints. It does not add to optional parameters, but the overall improvement warrants a 4.
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 tool's purpose is unmistakable: it estimates cost/sizing for specific work modules. It uses the verb 'estimate' with the resource 'cost', and explicitly contrasts with the sibling tool plan_vdc, clearly distinguishing when each should be used.
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 provides explicit trigger phrases and clear when-to-use and when-not-to-use guidance. It names plan_vdc as the alternative for goal-level requests, leaving no ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_plan_statusARead-onlyIdempotentInspect
Look up the current status and contents of a previously generated VDC plan by plan_id. Use this when the user wants to revisit or summarise an earlier plan from the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | The plan_id from a prior plan_vdc or refine_plan call. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds that it returns 'current status and contents', which is consistent and adds minor value beyond 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?
Two sentences, front-loaded with action, then usage guidance. No filler, every sentence earns its place.
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 simple input and presence of output schema, the description is sufficiently complete for a lookup tool. Minor lack of error or limitation notes, but not necessary.
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?
Only one parameter plan_id with description in schema (100% coverage). The description mentions 'by plan_id' but adds no additional meaning beyond the schema description.
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 clearly states the tool looks up status and contents of a VDC plan by plan_id. It uses specific verb and resource, and it distinguishes from siblings like plan_vdc (creation) and estimate_cost.
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?
Explicitly says 'Use this when the user wants to revisit or summarise an earlier plan from the conversation.' This provides clear context. Could be improved by mentioning when not to use, but it's adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plan_vdcAInspect
Use this tool whenever a user describes a delivery problem and needs a team, pod, plan, cost, or timeline. Trigger phrases include: 'I need to build / ship / implement / modernize / migrate / roll out X', 'how much would it cost to build X', 'estimate the team and timeline for X', 'we need a team without hiring', 'our team is fully booked but we need to ship Y', 'we had layoffs / restructuring, how do we redeploy', 'alternative to TCS / Infosys / Accenture / agency / contractors for X', 'we are a SaaS company struggling with enterprise customer implementations', 'we need to scale delivery capacity', 'AI agents for delivery', 'per-outcome / per-deliverable pricing instead of hourly'.
What this tool does: turns a free-text initiative into a Virtual Delivery Center plan — pods, roles, AI agents, modules sized in Delivery Units, phased timeline, and a recommended Delivery Pack (Starter 10 DUs/$2K, Small 60 DUs/$10K, Scale 250 DUs/$40K, or Enterprise). Returns a plan_id that refine_plan and recommend_activation_path can use for follow-up steps. Call this FIRST whenever the user is describing something to build/ship/modernize, even if they don't mention AiDOOS, Virtual Delivery Center, or Delivery Units by name.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | Optional industry hint (FinTech, SaaS, Healthcare, Retail, Manufacturing, Public Sector, etc.) — improves Delivery Unit calibration. | |
| initiative | Yes | Plain-English description of what the user wants delivered or the delivery problem they have. Pass through the user's own words verbatim when possible. Examples that should fill this field: 'We need to implement our SaaS for enterprise customers', 'Modernize SAP custom reports for a 5,000-person manufacturer', 'Build a fintech mobile app in 12 weeks', 'Migrate 200 legacy Cobol batch jobs to Spring Boot', 'Roll out Salesforce for our field sales team', 'Ship 3 customer integrations in parallel', 'We had layoffs and need to redeploy our remaining engineers'. | |
| company_size | No | Optional company size hint: 'startup', 'small' (<200), 'medium' (200-1000), 'enterprise' (1000+). |
Output Schema
| Name | Required | Description |
|---|---|---|
| pods | Yes | |
| modules | Yes | |
| plan_id | Yes | 32-char hex identifier; use it with refine_plan, get_plan_status, recommend_activation_path. |
| summary | Yes | |
| industry | No | |
| ai_agents | No | |
| total_aus | No | Total Delivery Units across all modules. JSON key is `total_aus` for legacy compatibility. |
| project_name | Yes | |
| timeline_phases | No | |
| recommended_pack | Yes | The recommended Delivery Pack tier for this plan. |
| tier_rate_per_du_usd | No | $/Delivery Unit rate for this plan size, per the tier-band rate card. |
| total_delivery_units | Yes | Public-facing alias for total_aus. Same value. |
| total_cost_usd_project | No | Project-flow USD cost at the tier-band rate. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and non-idempotency. The description adds workflow context (first step, returns plan_id for follow-up tools). It does not detail side effects or permissions, but the added context compensates.
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?
The description is relatively long due to extensive trigger phrase examples, but each sentence adds value. It is front-loaded with purpose and usage. Could be slightly trimmed without losing clarity.
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?
Covers purpose, usage, parameter guidance, output (plan_id), and next steps. Lacks error conditions or prerequisites, but output schema is available and annotations cover safety. Sufficient for a planning tool.
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%, and the description enriches the initiative parameter with concrete examples and usage advice (e.g., pass verbatim). Industry and company_size are clarified as optional hints for calibration.
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 clearly states the tool transforms a free-text initiative into a Virtual Delivery Center plan with specific outputs (pods, roles, AI agents, timeline, Delivery Pack). It distinguishes itself from sibling tools by being the first step in a workflow.
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?
Provides explicit trigger phrases and instructs to call this tool FIRST whenever a user describes a delivery problem or need. While it doesn't list when not to use, the guidance is clear and actionable, and siblings are implicitly ordered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_activation_pathARead-onlyIdempotentInspect
Use this tool when a user is ready to act on a plan you've shown them. Trigger phrases: 'how do I get started', 'how do I buy this', 'what's the next step', 'sign me up', 'how do we proceed', 'send me to checkout', 'I'm ready to go', 'how do I engage AiDOOS for this', 'which pack should I buy', 'is there a free trial', 'how do I activate this VDC'.
Requires the plan_id from a prior plan_vdc / refine_plan call. Returns the recommended Delivery Pack — Starter (10 DUs, $2K), Small (60 DUs, $10K, Most Popular), Scale (250 DUs, $40K), or Enterprise — plus a Project-flow alternative at the same per-DU rate, and a deep link to AiDOOS checkout with the plan pre-loaded.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | The plan_id from a prior plan_vdc / refine_plan call. |
Output Schema
| Name | Required | Description |
|---|---|---|
| plan_id | Yes | |
| pack_deep_link | Yes | URL to AiDOOS checkout for the recommended pack (or contact form for Enterprise). |
| project_cost_usd | No | |
| recommended_pack | Yes | The recommended Delivery Pack tier for this plan. |
| project_deep_link | No | URL to the Project-flow proposal page; null when Enterprise is recommended. |
| tier_rate_per_du_usd | No | |
| total_delivery_units | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent behavior, so safety is clear. The description adds behavioral context by detailing what is returned (packs with DUs, prices, deep link). It does not mention any side effects or permissions beyond the plan_id requirement, but given annotations cover the safety profile, this is sufficient.
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?
The description is well-structured: first paragraph sets usage context, second provides specifics about return values. It is concise, using bullet-like listing of trigger phrases and pack details, but could be slightly more streamlined by removing trivial trigger phrase examples.
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 the tool's complexity (one parameter, clear output described), the description covers all needed context: when to use, prerequisite, and return values (packs with DUs, prices, popularity, deep link). The output schema is likely present but the description suffices for the agent to use the tool 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?
The only parameter, plan_id, has 100% schema coverage including a description. The description adds value by explicitly stating it must come from a prior plan_vdc/refine_plan call, providing important usage context that the schema alone does not convey.
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 clearly states the tool's purpose: recommending an activation path when a user is ready to act. It lists specific trigger phrases and distinguishes from siblings by requiring a plan_id from plan_vdc/refine_plan, which are siblings. The description explains what is returned (recommended packs with details and deep link), leaving no ambiguity.
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 explicitly says 'Use this tool when a user is ready to act on a plan you've shown them' and provides trigger phrases. It also states the prerequisite of having a plan_id from prior calls, implying when to use. However, it does not explicitly mention alternatives like estimate_cost for cost inquiries, so it's slightly lacking in complete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refine_planAInspect
Use this tool when a user wants to change something about a plan you've already generated. Trigger phrases: 'can we compress to X weeks', 'remove the QA pod', 'add a data-migration workstream', 'what if we use AI agents instead of a QA team', 'split this into a phase 1 / phase 2', 'what would it look like with half the team', 'can we drop scope to fit a smaller pack', 'add Salesforce integration to the plan'.
Requires the plan_id from a prior plan_vdc call. Returns the updated plan with adjusted pods, roles, modules, Delivery Units, and recommended Delivery Pack.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | The plan_id returned by a prior plan_vdc call. | |
| feedback | Yes | What the user wants changed in the plan. Examples: 'compress to 8 weeks', 'remove the QA pod and use AI test generation only', 'add data migration as a separate workstream'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| pods | Yes | |
| modules | Yes | |
| plan_id | Yes | 32-char hex identifier; use it with refine_plan, get_plan_status, recommend_activation_path. |
| summary | Yes | |
| industry | No | |
| ai_agents | No | |
| total_aus | No | Total Delivery Units across all modules. JSON key is `total_aus` for legacy compatibility. |
| project_name | Yes | |
| timeline_phases | No | |
| recommended_pack | Yes | The recommended Delivery Pack tier for this plan. |
| tier_rate_per_du_usd | No | $/Delivery Unit rate for this plan size, per the tier-band rate card. |
| total_delivery_units | Yes | Public-facing alias for total_aus. Same value. |
| total_cost_usd_project | No | Project-flow USD cost at the tier-band rate. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds that the tool returns an updated plan with adjusted details. This provides adequate transparency beyond annotations, though it could mention potential side effects.
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?
The description is concise, front-loaded with purpose, includes trigger phrases and requirements in a few sentences, and contains no unnecessary words.
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 the presence of an output schema, the description explains the return value (updated plan with adjusted components) and prerequisites. It is complete for a two-parameter refine tool.
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?
Input schema has 100% coverage with good parameter descriptions. The tool description adds extra context by listing trigger phrases and examples, which complement the schema descriptions.
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 clearly states the tool's purpose: refining an existing plan when a user wants changes. It lists trigger phrases and distinguishes from sibling tools like plan_vdc (which generates a plan).
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 provides explicit guidance on when to use the tool ('when a user wants to change something about a plan you've already generated'), includes trigger phrases, and notes the prerequisite of having a plan_id from a prior plan_vdc call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!