Tendmark Buildings: Organize my building’s Clean Buildings compliance

Send a requirement

submit_request

Send a requirement to Tendmark Buildings. It is kept with a reference number. Your request is recorded with a reference number. Tendmark will review applicability evidence and existing work, establish data access needs, arrange qualified-role and implementation responsibilities, and develop a building-specific scope and indicative fee. We reply by email when you leave an address, carrying forward this brief and its open questions. Nothing is ordered or committed until you agree terms. Contact details are kept apart from the requirement, while we correspond or do business and for 24 months after, so a later request picks up where it left off; ask us to delete them at any time.

Input Schema

Name	Required	Description	Default
`need`	Yes
`action`	No
`budget`	No
`timing`	No
`contact`	No
`quantity`	No
`geography`	No
`continuation`	No
`specifications`	No
`requested_fields`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 6, 2026

addedInput schema / properties / continuation

Added value: +{
+  "properties": {
+    "id": {
+      "format": "uuid",
+      "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+      "type": "string"
+    },
+    "token": {
+      "pattern": "^[0-9a-f]{48}$",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "token"
+  ],
+  "type": "object"
+}

addedInput schema / properties / geography / properties / from
```
Added value: +{
+  "type": "string"
+}
```
addedInput schema / properties / geography / properties / to
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / requested_fields

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 30,
+  "type": "array"
+}

addedInput schema / properties / timing / properties / recurrence
```
Added value: +{
+  "type": "string"
+}
```

First observedNov 6, 2026

TDQS

B3.2/5.0

Behavior4/5

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

Beyond the annotations, the description discloses a lot: a reference number is issued, the downstream review process, email reply only if an address is supplied, no commitment until terms are agreed, and a 24-month contact-data retention policy with deletion on request. It does not warn that resubmission creates a new request despite idempotentHint=false, but the workflow and data-handling disclosures are well above the annotation baseline.

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

Conciseness3/5

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

The opening is front-loaded and the workflow sentences earn their place, but 'It is kept with a reference number. Your request is recorded with a reference number.' is a near-verbatim duplicate, and the closing retention sentence is long and comma-heavy.

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

Completeness2/5

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

For a 10-parameter, nested-object mutation with no output schema and no parameter descriptions, the definition should at minimum explain the continuation id/token returned for resuming and what the key parameters mean. It describes the business process instead, leaving the agent unable to construct a correct call or handle the response from the description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 10 parameters including nested budget, timing, quantity, geography, continuation, specifications and requested_fields, and the description explains none of them. The only implicit parameter guidance is that leaving an email address in contact triggers a reply, which barely compensates for the coverage gap.

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 opens with a specific verb and resource: 'Send a requirement to Tendmark Buildings.' That is clearly distinct from the offer-handling siblings (accept_offer, decline_offer), though it never names those siblings or states the hand-off relationship explicitly.

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?

Usage is only implied: 'Nothing is ordered or committed until you agree terms' hints that this is the pre-offer entry point that accept_offer/decline_offer later act on, but the tool never says 'use this first' or when NOT to use it. An agent must infer the sequencing from the sibling names.

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

All Tendmark Buildings: Organize my building’s Clean Buildings compliance tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?