Service Fusion MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools map cleanly to a specific resource and action, such as search_customers vs get_customer_details or create_job vs get_job_details. The main ambiguity is among search_jobs, get_customer_jobs, and get_todays_jobs, which all return job lists, though their descriptions do clarify the intended use case.
Naming Consistency5/5
Tool names consistently follow a get_/search_/create_ plus resource noun pattern in snake_case. Minor special cases like get_me, get_todays_jobs, and get_api_docs are still readable and do not break the overall naming system.
Tool Count3/5
24 tools is on the heavy side and falls within the borderline 16-25 range. Many tools are justified by the breadth of Service Fusion resources, but some are conveniences that overlap with search_jobs, and the number of enum/getter endpoints adds bulk to the surface.
Completeness3/5
The set covers read and search operations across jobs, customers, estimates, invoices, calendar tasks, equipment, and techs, and supports creating jobs, customers, and estimates. However, there are no update or delete operations for most resources, no invoice creation, and no calendar task creation, leaving some workflows as dead ends.
Average 4.1/5 across 24 of 24 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on September 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose that this is read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds only a filter list and does not disclose behavior like pagination, result ordering, match semantics, or how multiple filters combine. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the action and resource before listing filters. There is no filler or redundant explanation, though the long filter enumeration overlaps heavily with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 15 optional parameters and no output schema, the description is somewhat thin: it does not explain what a successful response contains, how filters interact, or pagination behavior beyond the schema defaults. Strong annotations and full schema coverage mitigate the gap but do not fully replace missing operational context.
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 description coverage is 100%, so every parameter already has a meaningful description including match type and defaults for pagination. The tool description merely summarizes filter names and adds no semantic value beyond the schema, so baseline 3 is appropriate.
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 clearly identifies the action ('Search') and resource ('estimates') and enumerates the main filter dimensions (status, customer, contact, address, category, source, PO number, dates). It is unambiguous, though it does not explicitly distinguish itself from siblings like get_estimate_details or search_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as get_estimate_details for retrieving a single estimate or search_jobs/search_customers for other entity types. The description implies a list-style search but provides no when-to-use or when-not-to-use direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is consistent with that (search is read-only). The description adds no further behavioral context about pagination, sorting, or filter combination semantics, so it stays at baseline.
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?
The description is a single, front-loaded sentence with no filler. Every listed filter category corresponds to real parameters, so it is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 optional parameters, no output schema) and the existence of multiple job-related siblings, this one-liner is a minimum-viable summary. It doesn't explain that filters combine, that all parameters are optional, or how results are returned, though individual parameter descriptions fill most of that gap.
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 description coverage is 100%, so each parameter is already documented individually. The description's list of filter categories ('status, customer, address, contact, category, source, dates, job/PO number') is a useful summary but doesn't add new meaning beyond the schema.
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 states a clear action ('Search jobs') and enumerates a broad set of filters, so an agent immediately knows this tool finds jobs by criteria. It doesn't explicitly contrast with job-specific siblings like get_job_details or get_todays_jobs, so it doesn't fully earn the top score.
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?
The phrase 'with flexible filters' implies this tool is for filtering jobs by various fields, which is a real usage cue. However, it gives no explicit when-to-use vs. alternatives (e.g., use get_job_details for a single known job or get_todays_jobs for today's schedule), so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation that is not idempotent and not destructive. The description adds the exact-match requirement, which signals that invalid or fuzzy inputs may fail, but it does not describe side effects, duplicate behavior, or what happens after creation.
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?
The description is two short sentences with zero filler. It front-loads the core action and then states the critical requirement, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The flat schema with complete parameter descriptions makes the definition adequate for invocation. However, with no output schema and no explicit sibling routing, the agent may be uncertain about the return value, creation workflow, or when this tool is preferred over create_job.
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 description coverage is 100%, so all parameters are already documented. The description mostly reiterates the exact-match constraint already present in the customer_name and category property descriptions, adding no new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a new estimate.' It also distinguishes this from sibling creation tools like create_job and create_customer by naming the estimate resource and noting the required exact customer name and category.
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?
The description gives a clear prerequisite — exact customer name and category — which helps the agent prepare inputs. However, it does not explicitly explain when to use this tool versus alternatives like create_job or search_estimates, so usage context must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotation hints false, the description carries the behavioral burden. It clearly identifies this as a creation operation and adds validation context via 'Requires an exact customer name, category, and status.' Still, it does not disclose the return value, duplicate behavior, or any other side effects beyond creation.
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?
Two short sentences with no filler. The core action is front-loaded, and the prerequisite forms a useful second sentence without adding unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The rich schema compensates for the short description by documenting all 13 parameters and their getter references. However, with no output schema and no positive annotation information, the description omits what the caller receives on success and gives little workflow context for a 13-parameter create operation.
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 description coverage is 100%, so the baseline is 3. The description adds no new parameter-level meaning: the required fields and 'exact' matching are already documented in the schema properties, so the description merely repeats what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Create a new service job.' This distinguishes it from sibling read/search tools like search_jobs and get_job_details, and from other creation tools like create_customer and create_estimate.
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 implied by 'Create a new service job' and the prerequisite of exact customer name, category, and status is stated. However, the description does not explicitly say when to choose this over alternatives, nor does it mention the getter tools referenced in the schema for satisfying exact-match values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'full record' context, indicating a comprehensive return, but does not disclose error behavior, authentication requirements, or any rate limits. With annotations covering the key behavioral aspects, this is adequate but not outstanding.
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?
The description is a single sentence with no filler or redundant phrases. It front-loads the main action and resource, then specifies the lookup key. Every word earns its place.
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, read-only, single-parameter tool, the description is nearly complete. It clearly identifies the required parameter and the expected return scope ('full record'). There is no output schema, so the description could have been more explicit about the returned fields, but this is a minor gap given the tool's simplicity and the annotations covering safety.
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 description coverage is 100%, and the parameter invoice_id is already described as 'Internal numeric invoice ID.' with an exclusiveMinimum. The description echoes 'internal ID' but adds no new semantic meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('a single invoice's full record'), and the lookup method ('by internal ID'). This clearly distinguishes it from sibling tools like search_invoices, which would search for invoices, and get_estimate_details, which targets a different resource type.
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?
The description implies the tool should be used when you already have the internal invoice ID and need the full record. However, it does not explicitly mention alternatives such as search_invoices for finding an ID, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile without description input. The description adds the scoping detail that all today's jobs are returned and technicians are included, but does not disclose return format, ordering, or pagination. This is consistent with annotations, so no contradiction.
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?
The description is a single clear sentence with no filler or repetition. It front-loads the main action and scope and then adds the technician inclusion detail.
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 read-only list tool with one optional documented parameter, the description is nearly complete: it identifies the exact resource and a key output detail. It does not mention routing to alternatives or return shape, but these are minor given the tool's simplicity and annotation coverage.
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 description coverage is 100%, so the status parameter is already fully documented as an optional comma-separated filter. The tool description adds no further parameter meaning, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get all jobs scheduled for today,' which clearly identifies the action and scope. It also specifies that assigned technicians are included, distinguishing it from broader searches or customer-scoped job tools.
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?
The description implies the tool is for retrieving today's job list, but it does not explicitly say when to prefer it over siblings like search_jobs or get_customer_jobs. There is no mention of exclusions or alternatives, so usage guidance is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict these. The description adds only that matching customer records are returned, but it does not disclose pagination behavior, match semantics, or response structure—though these are less critical given 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the action and the searchable field list, then state the return value. There is no filler, redundant repetition of the schema, or unnecessary background.
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 read-only search tool with 10 optional, fully documented parameters and strong annotations, the description plus schema gives an agent enough to invoke it correctly. The lack of an output schema is partially mitigated by the explicit statement that matching customer records are returned, though the exact response shape is not described.
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 description coverage is 100%, and each parameter already documents whether it uses full or partial matching. The description merely lists the same searchable fields without adding meaning beyond the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search for') and resource ('customers'), and enumerates the searchable fields: name, contact name, phone, email, address, city, and zip/postal code. This clearly distinguishes it from sibling search tools like search_jobs, search_invoices, and search_estimates, and from direct lookup tools like get_customer_details.
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?
The description makes the intended use clear: find customers by common identifying attributes. However, it does not provide when-not-to-use guidance or name alternatives, such as using get_customer_details when a customer ID is already known, so the agent must infer the boundary between search and direct lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only behavior is covered. The description adds that a 'full record' is returned, which is mildly useful, but it does not disclose any additional behavioral traits such as authentication requirements, potential errors, or whether the record could be null for a valid-looking ID. With annotations handling the safety profile, this is adequate but not exceptional.
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 short sentence with no filler. 'Get a single technician's full record by internal ID' front-loads the action, resource, and retrieval key in a compact, readable form. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one required parameter, strong annotations, and no output schema, the description plus parameter schema fully cover what an agent needs. The 'full record' phrase sets correct expectations about return content, and the single parameter leaves little room for ambiguity.
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 description coverage is 100% because tech_id is documented as 'Internal numeric technician ID.' The description's 'by internal ID' reinforces this but adds no new semantic detail beyond the schema, such as where the ID comes from or how to discover it. Baseline 3 is appropriate when the schema fully carries parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('a single technician's full record'), and the qualifier 'by internal ID' clearly distinguishes this from list-oriented siblings like get_techs. An agent can immediately tell this is an ID-based detail lookup, not a search or list operation.
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?
The description implies the tool should be used when you already have a technician's internal ID, but it never explicitly states when to use this instead of get_techs or any search tool. No exclusions or alternative routing are provided, leaving the agent to infer the usage context from the 'by internal ID' phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only that the record is complete and includes an optional repeat rule, which is helpful but not a major behavioral disclosure; with annotations carrying the load, this is adequate.
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 with no filler; the main action and distinguishing repeat-rule detail are both included. Every word earns its place.
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 single-parameter read-only lookup, the description combined with annotations and full schema coverage is nearly complete. It tells the agent what it will get ('full record'), including the special repeat-rule edge case, though it does not describe not-found behavior or response format in detail.
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?
The input schema has 100% description coverage and the single parameter, calendar_task_id, is fully described as an internal numeric ID. The tool description adds no additional parameter explanation, which is acceptable because the schema already documents everything needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a precise resource ('a single calendar task's full record'), and the lookup key ('internal ID'), and it adds the distinguishing detail that the response includes the repeat rule. This clearly differentiates it from the sibling list tool get_calendar_tasks and from get_job_details.
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?
The phrase 'a single ... by internal ID' clearly signals that this tool is for fetching one task when the ID is known, as opposed to listing tasks (get_calendar_tasks). It does not name alternatives or state explicit when-not-to-use conditions, but the context is unambiguous enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context by disclosing the return scope: the full record including contacts, locations, and custom fields. It does not address not-found behavior, but the safety profile is already well covered by annotations.
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 with no filler. The verb, resource, key, and response contents are all front-loaded, and every phrase adds distinct, useful information.
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 one-parameter, read-only get-by-ID operation, the description adequately conveys the lookup key and the response contents. However, since there is no output schema, the agent still lacks a precise return shape and error behavior, so it is slightly less than fully complete.
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?
The schema already describes customer_id as 'Internal numeric customer ID' with exclusiveMinimum 0, giving 100% schema description coverage. The description merely echoes 'internal ID' without adding additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a precise resource ('a single customer's full record'), the lookup key ('internal ID'), and the expected contents ('contacts, locations, and custom fields'). This clearly distinguishes it from sibling tools like search_customers and get_customer_jobs.
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?
The use case is implied: call this when you already have the internal customer ID and need the full record. However, it does not explicitly say when not to use it or mention alternatives like search_customers for lookup by name or email, so guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about customer scoping and single-record behavior, but it does not disclose pagination behavior, output format, or how customer_name is resolved beyond what the schema already says. This is acceptable but not rich.
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?
Two short sentences with no filler. The action and scope are front-loaded, the requirement is stated immediately, and the optional mode is separated clearly. Every sentence earns its place.
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?
Given the read-only annotations, full schema coverage, and no output schema, the description covers identity requirements, output fields, and optional single-record behavior. The only minor gaps are that the relationship between equipment_id and the required customer identifier is slightly ambiguous, and pagination is only discoverable from the input schema rather than the description.
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 description coverage is 100%, so every parameter is already documented in the schema. The description restates the customer_id/customer_name requirement and the equipment_id option, and it adds the equipment fields returned. This adds minor clarity but does not meaningfully extend the schema's parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific action and resource: 'Get equipment records for a customer' and enumerates the relevant fields (type, make, model, serial, warranty, custom fields). It also clearly distinguishes the optional single-record mode via equipment_id. No sibling tool duplicates this purpose, so an agent can confidently identify what this tool does.
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?
The description states the required input context: 'Requires customer_id or customer_name' and explains that equipment_id optionally fetches a single record. That gives clear guidance on when to call the tool. It does not explicitly mention alternatives or exclusion conditions, but there is no competing equipment sibling, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context such as sorting by most recent first and returning all jobs for a customer, but it does not mention pagination or result boundaries. This is acceptable but not highly detailed.
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?
The description is two sentences with no filler. The core function and sort order are front-loaded, followed immediately by the practical prerequisite. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup tool with annotations already covering safety and idempotency, the description provides the necessary scope, ordering, and prerequisite. No critical calling information is missing.
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 description coverage is 100%, so both parameters are already documented. The description adds a helpful workflow hint about finding the exact name via search_customers, but it does not provide substantial new parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('all jobs for a customer'), and the sorting behavior ('most recent first'). It also differentiates this from broad job-search tools by tying results to a customer name.
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?
The description gives clear context and a concrete prerequisite: 'Use search_customers first to find the exact name.' It does not explicitly list when-not-to-use alternatives, but the by-customer-name scope makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the scope of returned data, but it does not state behavior for missing/invalid identifiers or whether both parameters can be supplied.
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?
A single, front-loaded sentence that communicates purpose, identifiers, and response contents without filler. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-fetch tool with strong annotations and 100% schema parameter coverage, the description is complete. It tells the agent what the tool returns and how to identify the job; no output schema exists, so listing the included sections is especially useful.
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 description coverage is 100%: job_id and job_number are clearly described as alternatives in the input schema. The description simply restates this 'internal ID or display number' relationship and adds no new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Get complete details for a single job' by internal ID or display number. It also enumerates the returned content (techs, tasks, notes, charges, visit history), which clearly distinguishes it from broader search/list siblings like search_jobs or get_customer_jobs.
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?
The context is implied: use this when you need full details for one known job via job_id or job_number. However, it does not explicitly mention when not to use it or suggest alternatives such as using search_jobs first to find the ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and destructiveHint as safe. The description adds meaningful behavioral detail beyond those annotations: the endpoint documents no server-side filters, and correlation must be done manually using returned fields. It does not cover response shape or rate limits, but the main operational limitation is transparently disclosed.
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?
Two sentences with no filler: the first delivers the core purpose and context, the second isolates the important caveat. The most decision-relevant information, the lack of server-side filters, is front-loaded and clearly marked with a NOTE.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only paginated list with three optional, fully documented parameters, the description is complete. It explains what the tool returns, the entity relationships, and how to compensate for the lack of server-side filtering via returned ID fields. No output schema exists, but the description still gives enough guidance for correct invocation and interpretation.
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%, with page, sort, and per_page all already described including defaults and bounds. The description adds the high-level note that results are sorted and paginated, and that server-side filters are unavailable, but it does not deepen parameter-level semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('calendar tasks'), and expands on what calendar tasks are by naming the entity types they relate to (users, customers, jobs, estimates). It also implicitly distinguishes this from the sibling get_calendar_task_details tool by framing it as the sorted, paginated collection endpoint.
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?
The description gives clear context: this tool lists all calendar tasks and supports sorting/pagination. It explicitly warns that no server-side filters exist, so an agent won't attempt to pass unsupported filter parameters. It does not explicitly name an alternative for single-task lookup, like get_calendar_task_details, so it stops short of full when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful beyond-annotation context by disclosing the return composition (line items, techs, notes, payments). It does not cover error cases or auth, but these are less critical given 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and object, and the trailing list of included content earns its place. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only lookup, the description is complete: the schema documents the only input and the description enumerates the return content in the absence of an output schema. Sibling tools further contextualize how it fits into estimate workflows.
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% and the single parameter estimate_id is already described as an internal numeric estimate ID. The description's 'by internal ID' reinforces this but adds no new semantic information, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb-resource pair: 'Get complete details for a single estimate by internal ID.' The phrase 'single estimate' and the listed sub-resources (line items, techs, notes, payments) distinguish it from search_estimates and create_estimate without needing to open schemas.
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?
The description makes the usage context clear: call this when you need the full detail record for one estimate and already have its internal numeric ID. It does not explicitly name alternatives such as search_estimates for finding IDs, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds a critical non-obvious behavior: the endpoint has no server-side filters, and customer_name is applied as a client-side substring match on the fetched page only. This is exactly the kind of quirk an agent needs to know.
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?
Two sentences, each earning its place. The first states the action and key features; the second delivers a necessary caveat about filtering behavior. No redundant restating of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is complete: it covers what the tool does, how results are organized, and the surprising limitation of customer_name filtering. The schema handles pagination and sort details, and annotations cover the read-only safety profile, so nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful operational nuance for customer_name by clarifying it is not sent to the API and only matches within the fetched page, which goes beyond the schema's 'client-side substring filter' wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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: 'List invoices, sorted and paginated.' This clearly distinguishes it from siblings like get_invoice_details (detail lookup) and search_estimates/search_jobs (different resources), while the note about customer_name adds scope without blurring the core purpose.
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?
The description gives useful context: this is a paged, sorted listing tool, and customer_name filtering is only client-side against the fetched page. However, it does not explicitly name alternatives or say when to prefer get_invoice_details over this tool, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already classify this as read-only and idempotent. The description adds important behavioral detail beyond annotations: each named section returns only the primary list/create endpoint and excludes related sub-resources, which meaningfully affects how the result should be interpreted.
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?
The description is compact and well-structured: it states the purpose first, lists valid sections, then explains the key limitation and remedy. Every sentence contributes useful information with no repetition of schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter interface, the description fully covers what the tool does, what sections are available, what each section returns, and how to get broader coverage. Nothing critical is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'section' parameter and suggests 'index'/'full'. The description provides additional value by enumerating valid section names and explaining the scope of each section, which substantially enhances the agent's ability to choose a correct value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: looking up the Service Fusion API reference, with an explicit list of available sections. It is easily distinguished from sibling tools because it targets documentation rather than domain operations like jobs or customers.
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?
The description gives concrete guidance: use 'index' to see valid sections and 'full' when sub-resource or {id}-endpoint detail is needed. It doesn't explicitly contrast with sibling tools, but its role as a documentation lookup is clear enough that an agent can decide when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive. The description adds an important behavioral detail: the data is cached for 30 minutes, implying it may not reflect immediate changes. This goes beyond the annotations and helps the agent understand data freshness expectations.
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?
The description is compact and front-loaded. The first sentence identifies the action and resource, the second gives examples and use cases, and the third adds caching behavior. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only lookup tool, the description covers what it returns, how it should be used, and the caching caveat. There is no output schema, but the examples sufficiently convey the expected return format. No critical information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to explain parameter semantics. With zero parameters, the baseline is 4, and the description appropriately provides examples of return values rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool lists all available job categories, which is a specific verb-resource combination. It provides concrete examples ('Commercial Service', 'Residential Install') and contrasts with other value-list siblings like get_job_statuses or get_sources. An agent can immediately recognize what this tool returns and how it differs from similarly named tools.
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?
The description explicitly says to use these values when creating jobs/estimates or filtering by category, giving clear usage context. It does not explicitly name alternative tools or state when not to use it, but the guidance is specific enough that an agent will know when to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds the non-obvious behavioral trait 'Cached 30 minutes,' which is valuable and not present in the annotations. This surfaces a potential staleness consideration for the agent.
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?
Two sentences, no filler. The core listing behavior is front-loaded, followed by the use case and cache disclosure. Every sentence earns its place, and the description is appropriately sized for a simple enumeration endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema lookup tool, the description is complete: it states what is returned, why it's useful, and the caching caveat. An agent can confidently invoke this tool without further assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is trivially 100%. Per the baseline for zero-parameter tools, a score of 4 is appropriate. The description reinforces that the operation takes no input and returns the full set of statuses.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all available job statuses,' which is a specific verb and resource, clearly distinguishing this lookup tool from job-centric siblings like search_jobs or get_job_details. It also states the practical purpose: knowing valid status values when filtering or creating jobs.
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?
The description gives clear context for when to use the tool: 'Useful for knowing valid status values when filtering or creating jobs.' It doesn't explicitly name alternatives or exclusions, but among the sibling tools this is the sole status-enumeration endpoint, so the guidance is adequate without needing to differentiate further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds useful authentication context by noting the user is 'currently authenticated' and that the call verifies credentials. It does not describe the response shape, but for a zero-parameter read operation the behavioral picture is sufficient.
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?
The description is two short sentences that front-load the action and then give a practical use case. Every word earns its place; there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, simple read-only tool with strong annotations and no output schema, the description provides enough information for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter documentation is needed. The baseline of 4 applies because there are no parameter-related gaps to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the currently authenticated user's info.' This clearly distinguishes get_me from siblings like get_job_details and get_customer_details, which target different resources.
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?
The description explicitly says the tool is 'useful for verifying API connectivity and credentials,' giving an agent a clear when-to-use context. It does not name exclusions or alternatives, but no sibling serves the same current-user purpose, so the gap is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds a useful behavioral detail beyond annotations: results are cached for 30 minutes, which warns the agent that values may be slightly stale.
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?
The description is two sentences with no filler: it states the purpose, gives examples, explains downstream usage, and notes the cache duration. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only reference-list tool, the description is fully sufficient: it identifies what is returned, how to use it, and the caching behavior. No output schema exists, but for this simple list, the return value is self-evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description carries no parameter burden. Per the baseline for tools without parameters, this is appropriate, and the description still explains how the returned values should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'payment types' and includes concrete examples. This clearly distinguishes it from the entity-focused sibling tools like get_job_categories or get_job_statuses.
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?
The description explicitly explains when to use this tool: to obtain values for the payment_type field on create_job, create_customer, or create_estimate. It does not discuss exclusions or alternatives, but the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the useful behavioral detail that results are 'Cached 30 minutes,' which is not captured by the annotations. The annotations already indicate read-only, idempotent, and non-destructive behavior, so the additional cache disclosure adds meaningful context beyond the structured metadata.
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?
The description is two short sentences with no filler. The primary purpose is front-loaded, followed by the usage note and cache behavior, making every word valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool, the description covers purpose, usage context, and caching behavior. Annotations cover safety and idempotency, so nothing critical is missing for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema description coverage is 100%, so there is no parameter semantics burden on the description. The baseline for a zero-parameter tool is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all available lead sources' with a specific verb and resource. It also explains that these values are used when creating jobs, estimates, or customers, which helps distinguish it from sibling enumeration tools like get_job_categories or get_payment_types.
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?
The description gives concrete context on when to use the tool: 'Use these values when creating jobs, estimates, or customers.' It does not explicitly name alternatives or exclusion conditions, but the usage context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by stating that results are cached for 30 minutes and by summarizing the returned fields (names, contact info, role flags).
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?
The description is three short sentences with no filler. The primary action is front-loaded, and each sentence adds value: what it lists, what it returns, and how fresh the data is.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list endpoint, the description is complete. It covers the operation, the returned data shape, caching behavior, and the annotations cover safety. No output schema exists, but the description compensates by naming the return fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. Baseline for a zero-parameter tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List all technicians.' It also distinguishes itself from the sibling get_tech_details by focusing on the full list rather than a single technician's details.
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?
The phrase 'List all technicians' gives clear context for when to use this tool: when a complete list of technicians is needed. It does not explicitly name alternatives like get_tech_details, but the broad scope is clear and no exclusion criteria are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals a real API limitation: Service Fusion publishes no item schema for contacts/locations. It also interprets 403 responses as a credential-permission problem. These details help the agent react correctly to failures and avoid wasted calls.
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?
The description is three focused sentences, each carrying distinct information: the action, unsupported fields with the alternative, and the 403 error interpretation. There is no filler, repetition, or irrelevant detail.
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 create operation with one required parameter and no nested objects, the description covers the essential calling context, limitations, and error behavior. It does not describe the success response shape, but the absence of an output schema and the simplicity of the tool keep this gap minor.
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 schema already documents all three parameters and their constraints. The description does not add parameter-specific meaning, such as allowed formats or relationships between parameters. The note about contacts/locations is useful context but does not map to any parameter in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb and resource: 'Create a new customer record.' It also clarifies what cannot be done (contacts/locations), which distinguishes this tool's scope from broader customer-management operations. This makes it easy to tell apart from sibling tools like create_job and create_estimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when not to use this tool: contacts/locations cannot be set here and must be added via the web UI. It also explains the 403 error condition and directs the agent to use the web UI when credentials lack permission. This is clear, practical guidance with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Service-Fusion-MCP MCP server](https://glama.ai/mcp/servers/SinthetikIndustries/Service-Fusion-MCP/badges/card.svg)](https://glama.ai/mcp/servers/SinthetikIndustries/Service-Fusion-MCP)

Score Badge

Copy to your README.md:

[![Service-Fusion-MCP MCP server](https://glama.ai/mcp/servers/SinthetikIndustries/Service-Fusion-MCP/badges/score.svg)](https://glama.ai/mcp/servers/SinthetikIndustries/Service-Fusion-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SinthetikIndustries/Service-Fusion-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server