quantity-takeoff
Server Details
Auditable construction takeoffs with locked waste and conservative purchase rounding.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- jdhart81/viridis-agent-fleet
- GitHub Stars
- 0
- Server Listing
- viridis-agent-fleet
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 3.4/5 across 7 of 7 tools scored. Lowest: 2.4/5.
Each tool has a clearly distinct purpose: takeoff calculation, agent description, assembly/material pack retrieval and listing, result verification. No overlap or ambiguity.
All tool names follow a consistent verb_noun snake_case pattern (e.g., calculate_takeoff, list_assemblies, get_material_pack). No mixing of conventions.
7 tools is well-scoped for a quantity takeoff server, covering essential operations without bloat or deficiency.
The set covers listing, retrieval, calculation, and verification. Missing write operations (e.g., create/update) but these are not expected for a planning estimate service; minor gap in project-level input but not critical.
Available Tools
7 toolscalculate_takeoffAInspect
Calculate an auditable material takeoff from explicit geometry or a supported SmartScale/ProtoGen measurement payload. Returns net, explicit waste-adjusted, and conservative purchase quantities. This is a planning estimate, not a guaranteed material order or professional certification.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| options | No | ||
| payment_ref | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It discloses return types (net, waste-adjusted, conservative) and clarifies it's a planning estimate, but does not cover side effects, authentication, or rate limits.
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 with no fluff, front-loaded with the action verb. Every sentence adds value.
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?
Despite having an output schema, the description fails to explain parameter semantics for items, options, and payment_ref, leaving significant gaps for the agent to infer.
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%, and description does not add meaning for the three parameters (items, options, payment_ref). The mention of geometry and payload hints at items but lacks explicit detail.
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?
Description clearly states the tool calculates an auditable material takeoff from explicit geometry or supported payloads. It distinguishes itself from sibling tools like list_assemblies or get_material_pack by focusing on quantity calculation.
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?
Description implies usage when needing material quantities for planning, but does not explicitly state when not to use or provide alternatives. It offers clear context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_agentAInspect
Return fleet-standard capabilities, version, pack digest, disclaimer, composition role, and pricing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only lists output fields but does not disclose behavioral traits like side effects, authentication needs, rate limits, or whether it relies on external state. For a read-only tool, this is insufficient.
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 a single sentence listing multiple items, which is concise but slightly cluttered. It front-loads the verb 'Return' and immediately specifies the content, making it easy to scan.
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 the tool has no parameters and an output schema is available, the description provides sufficient textual explanation of the expected return fields. It does not cover prerequisites or context, but for a simple query tool, this is adequate.
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?
There are zero parameters, so the schema provides no parameter information. The description adds value by enumerating the specific data fields returned (capabilities, version, pack digest, etc.), which helps the agent understand what the tool 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?
The description clearly states the tool returns specific items (capabilities, version, pack digest, etc.) for an agent. It uses a specific verb 'describe' and resource 'agent', distinguishing it from sibling tools like calculate_takeoff or get_assembly.
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?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or situations where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_assemblyAInspect
Return one assembly's formula, required dimensions, material factors, purchase increment, sources, and material-pack lineage.
| Name | Required | Description | Default |
|---|---|---|---|
| assembly_type | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only retrieval operation without side effects, but does not explicitly state non-destructiveness or authorization needs. With no annotations, the agent must infer safety from the verb 'Return'.
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 a single, well-structured sentence of 16 words, front-loaded with the verb and resource, and every phrase contributes meaning.
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 simplicity (one parameter, no nesting) and the presence of an output schema, the description adequately lists the return fields. It omits nothing critical for understanding the tool's basic function.
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 0% and the description does not explain the 'assembly_type' parameter, its format, or allowed values. The parameter name is somewhat descriptive, but the description adds no additional semantic meaning.
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 it returns a single assembly's detailed information: formula, dimensions, material factors, etc. This distinguishes it from sibling tools like list_assemblies (which returns multiple) and get_material_pack (different resource).
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 implies usage when detailed assembly info is needed, but provides no explicit guidance on when to use vs alternatives or any prerequisites. Sibling tools exist (e.g., list_assemblies) but no comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_material_packBInspect
Return the bundled factors, densities, coverages, waste defaults, purchase increments, unit conversions, sources, and raw-pack SHA.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only lists return values but does not mention side effects, authentication needs, rate limits, or how the tool determines which material pack—especially concerning given zero parameters.
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 a single sentence that front-loads the purpose, but the list is long and somewhat verbose. It is efficient but could be slightly more compact.
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?
Despite having an output schema, the description lacks context on why or when to invoke this tool. It does not clarify whether it returns a default pack or which pack, leaving ambiguity for the agent.
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?
There are zero parameters, so the input schema is trivial. The description adds no parameter details but also does not need to; baseline of 4 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?
The description clearly states the verb 'Return' and lists the specific bundled items (factors, densities, coverages, etc.), distinguishing it from sibling tools like 'list_material_pack' which likely lists packs rather than returning detailed contents.
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?
No guidance on when to use this tool versus alternatives like 'list_material_pack'. The description implies retrieval of details but does not specify prerequisites or context, leaving ambiguity for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_assembliesAInspect
List supported assemblies, required dimensions, formulas, waste defaults, and the current material-pack digest.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral burden. It does not state that the operation is read-only or safe, nor does it mention any required permissions or side effects. The description only lists what is returned, not the behavior itself.
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 a single sentence that is front-loaded with the key action and resource, containing no extraneous words. Every part 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?
The tool is simple with no parameters and has an output schema, so the description adequately covers the return set. However, it could mention that it returns all supported assemblies, which is implied but not explicit.
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?
With zero parameters and 100% schema coverage, the description adds value by specifying the content of the return ('required dimensions, formulas, waste defaults, material-pack digest'), which goes beyond the empty input schema.
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 verb 'List' and the resource 'supported assemblies', which is distinct from sibling tools like 'get_assembly' (single) and 'calculate_takeoff' (action).
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?
No guidance is provided on when to use this tool versus alternatives such as 'get_assembly' for a single item or 'list_material_pack' for material packs. The context of usage is left entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_material_packAInspect
List the bundled material pack version, digest, coverage, shapes, rebar sizes, roof pitches, and explicit unsupported policy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only lists returned fields. Does not disclose side effects, permissions, or that it's a read operation. Relies on 'list' implying read-only, but insufficient for full transparency.
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?
Single sentence listing all items, front-loaded with 'List the bundled material pack'. Efficient but could be more structured (e.g., bullet points). 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 an output schema exists, description doesn't need to cover return format. It lists the fields provided, but omits context like authentication or scope. Good for a simple list 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?
No parameters in input schema (0 params, 100% coverage), so baseline is 4. Description adds value by specifying what the tool lists, compensating for the empty schema.
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 lists specific details of the bundled material pack: version, digest, coverage, shapes, rebar sizes, roof pitches, and unsupported policy. It distinguishes from siblings like get_material_pack (likely a single pack) and list_assemblies.
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?
No explicit guidance on when to use this tool vs alternatives like get_material_pack or list_assemblies. Usage is implied by name but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_resultCInspect
Recompute a takeoff audit hash, notary payload, pack currency, and QT9 unit-resolved conservation. Pass the prior result object as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| result_json | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool recomputes certain values and expects a prior result, but lacks details on side effects, required permissions, error behavior, or output structure beyond referencing an output schema.
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, but the first is a dense list of technical terms that reduces readability. The second provides clear instruction. Overall adequate but not optimally clear.
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 (many domain terms) and the presence of an output schema, the description fails to provide sufficient context about the role of this tool in the workflow or how it relates to siblings like 'calculate_takeoff'. More context is needed for correct invocation.
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 0%, so description must compensate. It adds meaning by specifying that 'result_json' should contain the prior result object as a JSON string, clarifying the expected format beyond the schema's 'string' type.
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 uses domain-specific jargon like 'takeoff audit hash', 'notary payload', 'pack currency', and 'QT9 unit-resolved conservation' without clarifying what the tool actually does. The verb 'recompute' suggests recalculation, but the overall purpose is unclear for a general AI agent.
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?
No guidance on when to use this tool versus siblings. The instruction 'Pass the prior result object as JSON' indicates how to invoke it but not the context or prerequisites. No alternatives or exclusions mentioned.
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!
Your Connectors
Sign in to create a connector for this server.