Fixed-fee software consultancy. Ask about scope, terms, and live capacity.
Scored across 5 tools
Each tool targets a distinct information need: capacity/availability, contact channel, service catalog, engagement/billing model, and the discovery instrument. There is no meaningful overlap, so an agent can select unambiguously based on the question being asked.
All five names follow a clean snake_case verb_noun pattern (check_capacity, get_contact, list_services, get_*). The verbs vary (get vs list vs check), but each is semantically appropriate and the structure is predictable.
Five tools is well-scoped for a read-only informational/advisory layer. Each tool earns its place by covering a discrete pre-sales question an agent would need before proposing engagement.
The surface covers the core pre-engagement questions: scope (services), availability (capacity), terms (engagement model), entry offer (discovery instrument), and contact path. Minor gaps exist—no explicit inquiry-submission or proposal tool—but the read-only intent makes these acceptable workarounds.
Check whether McGill Technologies can take on new work right now. Returns concurrent engagement slots, slots in use, and slots open. Call before proposing a start date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the three returned values (concurrent slots, slots in use, slots open), which is useful, but never states that the operation is read-only/has no side effects, nor how current the capacity snapshot is.
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, zero filler, and the purpose is stated first with the actionable instruction last. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description responsibly names the three values returned, and the call-timing guidance is sufficient for a no-argument read tool. Only the read-only/side-effect guarantee and data freshness are left implicit.
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, so per the rubric the baseline is 4. There is no argument syntax the description could usefully elaborate on, and it correctly does not invent any.
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 ('check') and resource ('whether McGill Technologies can take on new work right now'), plus the exact data returned. It is trivially distinguishable from the get_* siblings, which fetch contacts, instruments, models, and services rather than live capacity.
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 an explicit trigger condition — 'Call before proposing a start date' — which is exactly the decision context an agent needs. It does not name alternatives, but no sibling tool covers capacity, so there is nothing to route against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get how to reach McGill Technologies and what the preferred first step is. Returns the contact channel and service area. Does not send anything.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and does add real behavioral context: it explicitly states the tool does not send anything, resolving the main ambiguity for a tool named 'contact'. It also names the returned data (contact channel, service area), though it omits any error or fallback behavior.
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 the core purpose and return values front-loaded and no filler. Slightly awkward phrasing in 'Get how to reach...' but structurally efficient.
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, side-effect-free lookup with no output schema, the description is largely sufficient: it says what is returned and confirms no message is sent. A note on the format of the returned channel data would make it fully 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?
The tool takes zero parameters, so the baseline of 4 applies. The description appropriately adds no parameter discussion, as there is nothing to disambiguate.
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 and resource: retrieves the contact channel and service area for McGill Technologies. It is clearly distinguishable from siblings like list_services or get_engagement_model, though it does not explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent infers it should call this when it needs contact info or a first step. The phrase 'Does not send anything' hints at a boundary (it is not an outreach tool) but no when-to-use condition or alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Discovery Instrument: the fixed-fee two-week diagnostic that most engagements begin with, including fee, duration, deliverables, and how the fee is credited against a later build SOW.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose the payload contents (fee, duration, deliverables, fee crediting). However, it says nothing about permissions, freshness, or whether the returned terms are negotiable, which a spec-retrieval tool would ideally clarify.
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 that defines the resource and enumerates its included fields with no wasted words. Structure is efficient and immediately usable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and no annotations, the description supplies the essential context: what the object is and what it contains. It is nearly complete for such a simple getter, though it omits any statement of source or reliability of the terms.
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, so per the baseline the schema fully covers the input contract. There is nothing for the description to add or compensate for on this dimension.
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?
Names a specific verb (Get) and resource (Discovery Instrument) and immediately defines it as 'the fixed-fee two-week diagnostic that most engagements begin with,' which is more than a restatement of the name. It does not explicitly differentiate from siblings like get_engagement_model or list_services, so it falls short of a 5.
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 'that most engagements begin with' implies when this offering is relevant, but there is no explicit when-to-use or when-not-to-use guidance, and alternatives such as get_engagement_model are not mentioned. 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.
Get how McGill Technologies contracts and bills: pricing structure, who owns the source code and IP at the end, and whether there is any lock-in or required retainer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden. The verb 'Get' plus the informational subject matter implies a read-only, non-mutating call and it discloses the scope of what is returned, but it says nothing about permissions, sourcing of the data, or freshness. For a zero-parameter static-info tool that 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with a colon-delimited list of the three returned topics. No filler, no restatement of the title, and the reader knows the payload immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must describe returns, and it does so by naming the three content areas an agent would get back. It stops short of stating the return shape or format, but for a zero-parameter informational getter this is close to 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?
The tool takes no parameters, so there is nothing for the description to clarify beyond the input schema. The baseline of 4 applies; the description adds no parameter detail because none is needed.
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 concrete verb ('Get') and a concrete resource ('how McGill Technologies contracts and bills'), then enumerates the exact facets returned: pricing structure, IP/source-code ownership, and lock-in/retainer terms. This distinguishes it implicitly from the sibling tools, which cover capacity, contact, discovery and services, though it never names a sibling 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?
There is no explicit when-to-use statement, no prerequisites, and no named alternative. Usage is only implied by the content scope ('contracts and bills'), which is enough for an agent to infer that this is the commercial-terms lookup versus get_contact or list_services, but nothing is spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the categories of work McGill Technologies takes on, with the situations each one typically applies to. Use this to determine whether a problem is in scope.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Optional service id to filter to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral disclosure. 'List' implies a safe read, and it describes what the returned content contains, but it says nothing about pagination, whether the id filter returns multiple or one, or any access constraints.
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 purpose front-loaded and the intended use second. No filler, though the second sentence could be folded into the first without loss.
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 simple one-parameter read tool with no output schema, the description adequately conveys both purpose and return content (categories plus applicable situations). It is nearly complete; only the filter's return behavior is left unstated.
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 100% for the single optional 'id' filter, so the schema already documents it. The description adds no filtering semantics or format detail beyond the schema, which is the expected baseline when the schema does the work.
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 (List) and resource (categories of work McGill Technologies takes on) and describes the payload shape (situations each applies to). It is clear what the tool returns, though it does not explicitly differentiate itself from the other get_*/check_* siblings.
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?
Explicitly names the use case: 'Use this to determine whether a problem is in scope.' That is clear triggering context, but it names no alternatives or exclusions, so it falls short of a full when/when-not statement.
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.
check_capacityget_contactget_discovery_instrumentget_engagement_modellist_servicesPaid remote MCP for spec driven development acceptance gate MCP, structured receipts, audit logs, an
Free preflight and exact-price discovery for paid website and AI-agent audits.
Launch and operate a SaaS from one conversation — domain, hosting, email, Stripe, ads, security.
Freelance business manager — clients, proposals, invoices, time tracking, scope, and follow-ups.