DFW multi-location kitchen exhaust cleaning scope, access and proposal coordination
Scored across 7 tools
Each tool has a distinct action-resource pairing: submit_request, request_status, inspect_offer, accept_offer, decline_offer, release_payment, and describe_business are clearly separable. The only mild overlap is that request_status also surfaces linked offers, but inspect_offer is explicitly for exact offer terms and payment links, so the boundary remains clear.
Most names follow a consistent snake_case verb_noun pattern: accept_offer, decline_offer, describe_business, inspect_offer, release_payment, submit_request. The outlier is request_status, which is noun_noun rather than verb_noun, but it remains readable and predictable.
Seven tools are well scoped for a request-to-offer-to-payment workflow. Each tool earns its place: one for business context, one for submitting a request, one for checking status, one for inspecting offers, two for responding to offers, and one for payment condition release.
The core lifecycle is covered: submit a request, check status, inspect offers, accept or decline, and release a payment condition, with payment links provided through inspection. Minor gaps exist, such as no explicit tool to update or cancel a request and no direct mechanism for contact-detail deletion despite that being mentioned.
Place an order on terms you have inspected and the buyer has authorized you to accept. Requires the exact terms hash and explicit acceptance. Follow inspect_offer later for payment links and verified payment state.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | Yes | ||
| token | Yes | Private token from your receipt or customer link; keep it for later visits | |
| accept | Yes | ||
| organization | No | ||
| terms_sha256 | Yes | ||
| purchase_order | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the mutation and idempotency profile is covered structurally. The description adds real value by stating the authorization precondition and the exact-hash/explicit-acceptance requirement, but says nothing about what happens on a hash mismatch, token reuse, or failure modes.
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?
Three short sentences, front-loaded with the action and the preconditions, ending with the follow-up step. No filler, though the final sentence could be tightened.
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?
For a mutation tool with no output schema, the description covers the critical preconditions and the natural next step, which is the most important part. It omits the optional parameters' purpose and any indication of what a successful acceptance returns or how the token is used afterwards, so it is adequate rather than complete.
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 only 14% across 7 parameters, so the description must carry weight. It explains terms_sha256 ('the exact terms hash') and accept ('explicit acceptance'), but is silent on id, name, organization and purchase_order, leaving half the surface undocumented in both places.
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 states a specific action (place an order) on a specific resource under stated conditions, and distinguishes itself from the read-only sibling inspect_offer by framing itself as the committing step. It is clear what the tool does, though it never names the most obvious sibling alternative, decline_offer.
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?
It gives an explicit precondition sequence: terms must already have been inspected, the buyer must have authorized acceptance, and inspect_offer should be followed afterwards for payment links. The only gap is that it doesn't say when to call decline_offer instead or what to do if terms were not inspected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decline an issued offer on its inspected terms.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| token | Yes | Private token from your receipt or customer link; keep it for later visits | |
| reason | No | ||
| terms_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is known without the description. The description adds essentially nothing beyond that: it does not say whether a decline is final or reversible, whether the offer is released or cancelled, or that the terms hash is validated before committing. For a destructive action that gap is material.
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 front-loaded sentence with no filler. It is efficient, but its brevity is partly under-specification rather than disciplined compression.
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?
A destructive, idempotent tool with three required parameters, no output schema, and an implied two-step workflow with inspect_offer. The description does not explain the terms-hash handshake, the reason field, or what the caller gets back, leaving an agent to guess at a consequential operation.
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 only 25%; only 'token' is documented. The required 'terms_sha256' is an opaque hash whose provenance (presumably an inspect_offer result) and mismatch behavior are unexplained, and 'reason' (maxLength 500) is never mentioned. With low coverage the description needed to compensate and does not.
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?
States a specific verb plus resource ('Decline an issued offer') and is readily separable from the sibling accept_offer. The 'on its inspected terms' qualifier signals a prerequisite relationship with inspect_offer, though it is phrased obscurely.
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 phrase 'on its inspected terms' implies the offer must be inspected before declining, and that this is the counterpart to accept_offer. It never says when a decline is appropriate, what alternatives exist, or what happens if the offer was not inspected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What Fluefold 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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds that the content covers the business, the request lifecycle, and request fields, which is useful scope context. With no output schema, it could have said more about the form of the response (prose vs structured), so it lands at adequate rather than rich.
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 short sentence with no filler, and the three content areas are listed compactly. The phrasing is slightly clipped and the leading topic ("What Fluefold does") is less actionable than a verb-first statement would be, but nothing is wasted.
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?
For a zero-parameter informational tool with full annotation coverage and no output schema, the description tells the agent what topics the response covers. It does not state the response format or length, which matters when there is no output schema to consult, so it is complete enough to call but not to predict.
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 schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.
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?
"What Fluefold does, what happens to a request, and the request fields" names the content topics but supplies no verb describing the action (e.g. "returns documentation about"). It implicitly distinguishes itself from the transactional siblings by being informational, but an agent must infer that this tool returns reference text rather than performing an operation.
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?
There is no when-to-use guidance and no alternatives are mentioned. The agent is not told that this should be consulted before calling submit_request, nor that it is the only non-transactional sibling, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the exact authorized terms, terms hash, order state and processor payment links. Use the offer link credentials, or credentials of the request explicitly linked to this offer.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| token | Yes | Private token from your receipt or customer link; keep it for later visits |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is fully covered. The description adds real value by listing the returned data and the authorization source, but says nothing about failure modes (e.g. invalid or expired token, unknown id) or whether the terms are locked once accepted.
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 compact sentences with the payload description front-loaded and the authorization requirement second. Nothing is wasted, though the credential sentence is dense enough that a third short clause clarifying id would have been better spend than nothing.
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?
For a read-only inspector with no output schema, the description does the essential job by enumerating what comes back and what credentials are required. The remaining gap is the ambiguity of the id parameter against a 50%-covered schema.
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 50%: token is documented in the schema as the private token from a receipt or customer link, while id carries only format/pattern constraints. The description's credential sentence reinforces token's role but leaves it ambiguous whether id is the offer id or the linked request id, which is exactly the gap an agent needs filled.
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?
"Read" is a specific verb and the resource is enumerated precisely: authorized terms, terms hash, order state and processor payment links. This clearly separates it from mutation siblings like accept_offer and decline_offer, though no sibling is named explicitly.
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 second sentence gives credential context (offer link credentials, or credentials of the request linked to the offer) which implies when this tool is callable, but it never states when to choose inspect_offer over request_status or describe_proposition, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm a payment condition only where the inspected order allows the customer to release it. This records approval; it does not pay the processor.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | No | ||
| token | Yes | Private token from your receipt or customer link; keep it for later visits | |
| confirm | Yes | ||
| payment | Yes | ||
| terms_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the mutation/idempotency/destructiveness profile, and the description adds the genuinely useful clarification that it records approval without paying the processor. However, it does not explain failure behavior when the order disallows release (error vs. no-op), what a successful record looks like, or what the terms hash represents, leaving real behavioral gaps for a write operation.
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 short sentences with the gating condition front-loaded and a high-value negative clarification second. Every clause earns its place and nothing is padded.
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 description covers purpose and the key semantic caveat, but for a mutation tool with no output schema and near-zero parameter documentation, it leaves the agent without guidance on inputs, error conditions, or the result of the call. Adequate as a minimum, incomplete given the tool's complexity.
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 six parameters and only 17% schema coverage, the description must carry parameter meaning and does not. It never mentions the token, terms_sha256, payment, or the const true confirm flag, so an agent must guess at the meaning of terms_sha256 and the free-text payment field from the schema alone.
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?
States a specific action (confirms a payment condition / records approval) and a specific scope (only where the inspected order allows the customer to release it). It implicitly points at the inspection prerequisite rather than naming a sibling like inspect_offer, but the operation is unmistakable and distinct from accept_offer or submit_request.
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?
Gives a clear precondition for use ('only where the inspected order allows the customer to release it'), which tells the agent to inspect first and not to release unconditionally. It does not explicitly name the sibling to call for that inspection or state when not to use it, so it falls short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume a requirement using the receipt credentials. Read the recorded requirement and any linked offers. Contact details are kept apart.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| token | Yes | Private token from your receipt or customer link; keep it for later visits |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. Beyond that, the description adds two useful behavioral facts: access requires receipt credentials (an auth prerequisite not expressible in annotations), and returned data separates contact details from the request record — useful privacy context for interpreting the response.
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?
Three short sentences with no filler, and the credential requirement is front-loaded. The wording is slightly awkward ('Resume a requirement', 'kept apart'), but nothing is wasted.
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?
For a two-parameter, read-only, non-destructive status lookup with no output schema, the description covers the auth requirement and sketches what is returned (recorded requirement plus linked offers). The main residual gap is that the 'id' parameter's meaning is left unexplained.
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 50% schema coverage (only 'token' is documented in the schema), the description should compensate, and it partially does by framing both parameters as 'receipt credentials'. However it does not explain what 'id' is (a UUID request identifier) nor how it relates to the token, leaving one of two required parameters undocumented in both places.
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 conveys that it retrieves a previously recorded request plus any linked offers, which is the right resource, but the phrasing 'Resume a requirement using the receipt credentials' uses vocabulary ('resume', 'requirement') that does not match the tool name 'request_status'. An agent can roughly infer the purpose but gets no clean verb+resource statement and no differentiation from siblings like inspect_offer or describe_proposition.
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?
There is no explicit when-to-use statement and no alternative named. The mention of 'receipt credentials' implies this is the follow-up call after submit_request, but the agent must infer that from the sibling list rather than from the text.
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 Fluefold. It is kept with a reference number. A request is recorded with a reference number. Fluefold will reconcile the site requirements, seek suitable provider scope and window options, and develop comparable nonbinding terms by email to the address left. No visits are booked by this request; nothing is ordered or committed until the buyer agrees scope, timing and price. 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 | ||
| continuation | No | ||
| specifications | No | ||
| requested_fields | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only declare it is a non-read-only, non-destructive, non-idempotent, closed-world write), the description discloses the downstream workflow (reconcile requirements, seek provider scope and window options, develop nonbinding terms by email), the non-committal nature of the submission, and a 24-month contact-data retention policy with deletion on request. That is substantial behavioral context an agent could not infer from the 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?
The workflow and commitment disclaimers are front-loaded and valuable, but the opening two sentences duplicate the same fact about a reference number, and the retention sentence is dense and tacked on. Trimming the repetition would sharpen it without losing content.
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?
For a 10-parameter submission tool with no output schema, the description adequately explains the business process, the nonbinding nature, and data handling, but leaves the majority of the input surface unexplained. An agent would still be guessing at how to populate action, quantity, geography, specifications, and continuation.
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 10 parameters including nested objects, so the description carries the full burden and largely fails. It only obliquely touches contact ("the address left"), need ("requirement"), and budget/timing ("scope, timing and price"); it says nothing about the action enum, quantity, geography, specifications, requested_fields, or the continuation id/token pair used to resume a prior request.
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 opens with a specific verb and resource ("Send a requirement to Fluefold") and states the outcome (recorded with a reference number), which distinguishes it from siblings like accept_offer and request_status. It loses a point for the redundant restatement "It is kept with a reference number. A request is recorded with a reference number."
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?
It clarifies what the tool does NOT do ("No visits are booked... nothing is ordered or committed until the buyer agrees scope, timing and price"), which is useful boundary-setting. However, it never routes the agent to alternatives such as request_status for follow-up or inspect_offer for reviewing returned terms, so usage is only implied.
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.
accept_offerdecline_offerdescribe_businessinspect_offerrelease_paymentrequest_statussubmit_requestAustin kitchen openings: grease, hood and backflow scope, schedule and estimate requests
Requests for grease trap pumping across Austin restaurant locations on one calendar and invoice
Restaurant fire-safety & service-interval tracking (NFPA 96/17A) — read-only demo tools.
Verified DFW home-services directory. AI agents submit listings and find bookable pros.
Add one secure layer between your agents and this server.