Skip to main content
Glama
Sign In
Buildertrend MCP Server

Buildertrend MCP Server

by cotlet-connect
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

buildertrend_guide

Explains how to navigate Buildertrend, sign in, read job schedules, and write daily logs so agents can complete account tasks correctly.

Instructions

How to work in Buildertrend (read job schedules and write daily logs): its screens and the sign-in link. Call this first.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "buildertrend_guide"
  }
}

Input Schema

NameRequiredDescriptionDefault
taskNoWhat you want done in Buildertrend, in your words.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the tool returns screens and a sign-in link, which implies informational or read-only behavior, but it does not explicitly state that it performs no writes, whether authentication is required, or what the response format is.

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

Conciseness5/5

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

One sentence plus a directive, with the key routing instruction front-loaded. No wasted wording, and the scope is conveyed immediately.

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

Completeness4/5

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

For a simple guide tool with one optional parameter, the description covers purpose, content, and call ordering. It could add more about the return shape or how the free-form task parameter shapes the guidance, but the essentials are present.

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?

Schema coverage is 100%, so the single task parameter is fully documented in the schema. The description adds no further syntax or examples for how the free-form task value is interpreted, so the baseline 3 applies.

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 names a specific resource—Buildertrend guidance—and scopes it to reading job schedules and writing daily logs, plus screens and the sign-in link. 'Call this first' helps distinguish it from the sibling action tools, though it does not explicitly label itself as a guide versus an action tool.

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

Usage Guidelines4/5

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

It explicitly says 'Call this first,' giving clear ordering relative to the sibling tools. It does not state when not to use it or name specific alternatives, but the first-call instruction covers the main usage decision.

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