Request managed hive placement, ongoing care and Texas agricultural valuation documentation
Scored across 2 tools
The two tools serve clearly separate roles: one is read-only business/information retrieval, the other is a write-style submission action. An agent cannot plausibly confuse 'tell me about the business' with 'send a requirement,' and the descriptions reinforce the distinction.
Both names follow a consistent verb_noun snake_case pattern (describe_business, submit_request). The verb choices accurately signal read vs. write intent.
Two tools is thin even for an intake-only service; the lifecycle effectively stops after submission. It is defensible for a minimal contact/form endpoint, but leaves little for an agent to work with.
Intake is covered end to end (learn about the business, then submit), and the description explains the reference number and follow-up process. However, there is no way to check a request's status, retrieve it by reference, or withdraw it — dead ends after submission.
What Balcones Apiary Co. does, what happens to a request, and the request fields.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description contributes only that the payload covers business description, request handling, and request fields. With no output schema, it could say more about the shape of the returned information.
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?
A single sentence split into three parallel content items, front-loaded and free of filler. It is efficient but so terse that it reads almost like a table of contents rather than a definition.
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?
With no output schema, the description needs to carry the burden of explaining what comes back, and it only sketches that at a high level. For a zero-parameter informational tool this is adequate but thin; it does not say whether the result is prose, structured data, or how request fields are presented.
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 tool takes zero parameters and the description correctly implies no input is required. Nothing is left ambiguous on the input side, so the baseline for a no-parameter tool applies.
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 names the specific content the tool surfaces: the company's activities, the request lifecycle, and the request fields. That distinguishes it from the sibling submit_request, which performs rather than explains. It stops short of an explicit verb like 'returns' or 'explains', leaving the action implied rather than stated.
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?
Usage is only implied: an agent can infer this is the orientation/reference call to make before or instead of submit_request. There is no explicit 'use this when' statement, no mention of the sibling, and no exclusions, so the routing must be inferred from the title and sibling name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a requirement to Balcones Apiary Co.. It is kept with a reference number. A successful submission is recorded with a reference number. When an address is left, Balcones Apiary Co. replies by email. Balcones evaluates district rules, eligible area, history and site needs, seeks placement options and prepares feasibility, a management and documentation scope and proposed written terms. Nothing is ordered or committed until the owner agrees 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.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | ||
| action | No | ||
| budget | No | ||
| timing | No | ||
| contact | No | ||
| quantity | No | ||
| geography | No | ||
| specifications | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: each submission gets its own reference number (consistent with idempotentHint=false), email reply only if an address is left, no commitment until written terms are agreed (consistent with destructiveHint=false), and explicit data-handling terms including 24-month contact retention, separation of contact data, and deletion on request. It stops short of describing the response shape or error modes for a tool with no 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?
Purpose is correctly front-loaded, but the paragraph is padded and repetitive — "It is kept with a reference number" and "A successful submission is recorded with a reference number" say the same thing twice. The enumeration of Balcones' internal evaluation steps earns little for an agent deciding how to call the tool.
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?
Good coverage of process, consent and privacy for a mutation-style submission tool, and the reference number partially compensates for the missing output schema. But with 8 largely undescribed parameters and no return-format detail, an agent still cannot tell what a filled-in request should contain or what comes back.
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% across 8 parameters (including nested budget/quantity/timing/geography and a 10-value action enum), so the description must carry the burden and it does not. The only parameter-adjacent signal is "when an address is left," which hints that contact.email is optional; action, budget, quantity, timing, geography and specifications are never mentioned.
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?
Opens with a concrete verb+resource+recipient: "Send a requirement to Balcones Apiary Co." and clarifies it is recorded with a reference number. Sibling differentiation is absent — describe_business is never mentioned, so the agent must infer that this is the write/request path rather than the informational one.
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?
Implied context exists (submit when you have a need; "nothing is ordered or committed until the owner agrees terms" tells the agent it is safe to submit before any purchase decision). However, there is no explicit when-to-use vs. describe_business, no prerequisites, and no statement of what to do on failure or duplicate submission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
describe_businesssubmit_requestQuote restrooms, trailers, handwash, tanks, dumpsters, fencing, storage, water, and power.
Requests for grease trap pumping across Austin restaurant locations on one calendar and invoice
Start a 7-day placement trial: card on file, cancel anytime, measured agent hops.
Add one secure layer between your agents and this server.