Look up individual contacts, projects, opportunities and schedules.
Scored across 6 tools
The tools are mostly distinct: contacts are read by id, email, or phone, and opportunities, projects, and schedules are separate resources. The main potential confusion is choosing among the three contact lookup variants when the agent may not know which identifier is available, though the descriptions clarify the intended key.
All tools follow a highly predictable pattern: constructiononline_get_<resource>, with _by_email and _by_phone suffixes used consistently for contact lookup variants.
Six tools is well within the appropriate range and each tool has a clear, non-redundant role in the read-only lookup surface.
The surface only supports reading records by known identifiers, with no list/search operations to discover ids and no create, update, or delete operations. This creates significant gaps for common agent workflows in a construction management domain.
Read one contact using its known id. Returns selected operational fields. Notes, permissions, attachment data and unrelated personal or payroll fields are omitted. Read-only; requires customer API access.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses the shape of the response (selected operational fields), enumerates what is omitted (notes, permissions, attachments, payroll fields), and states the auth prerequisite ('requires customer API access'). That is real added context, though the return format itself is not described.
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?
Four short, front-loaded sentences with no filler; the omission list and auth note each earn their 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 usefully summarizes what is and isn't returned plus the auth requirement, which is enough for an agent to call it correctly. Only minor detail (error behavior for unknown ids) is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required param. The description clarifies that the id identifies a contact and must be known in advance, but adds no format, range, or validation detail beyond the schema's integer type.
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 ('Read one contact') and constrains it to lookup by 'known id', which implicitly separates it from the get_contact_by_email/phone siblings. It stops short of naming those alternatives, so it is clear but not fully differentiated.
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 'using its known id' implies you should already have the identifier and hints at the by-email/by-phone alternatives, but there is no explicit when-to-use or 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.
Read one contact using its known email. Returns selected operational fields. Notes, permissions, attachment data and unrelated personal or payroll fields are omitted. Read-only; requires customer API access.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, but the description adds real context beyond them: the shape of the return (selected operational fields only), the explicitly omitted data (notes, permissions, attachments, payroll), and the customer API access requirement. That goes meaningfully beyond the annotation profile.
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, front-loaded sentences: action and key first, return scope second, safety/prerequisite last. No filler and nothing redundant.
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 compensates by naming what is returned and, importantly, what is omitted, so an agent knows not to expect notes or permission data. What remains thin is failure behavior (what happens if no contact matches the email).
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?
Only one parameter, and the schema's email format/pattern/maxLength already define its syntax fully. The description adds only the qualifier 'known', implying an exact-match lookup rather than a search, which is a small but genuine addition over the schema.
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 ('Read one contact') plus the lookup key ('known email'), which cleanly separates it from the sibling get_contact_by_phone and the id-based get_contact. An agent can pick it without opening the schema.
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?
'using its known email' establishes the precondition for choosing this tool over get_contact or get_contact_by_phone, and the read-only note confirms it is a safe lookup. It does not explicitly state when NOT to use it (e.g., the fallback if the email is unknown), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one contact using its known phone. Returns selected operational fields. Notes, permissions, attachment data and unrelated personal or payroll fields are omitted. Read-only; requires customer API access.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description's real contribution is the field projection ('selected operational fields'; notes, permissions, attachments, payroll omitted) and the access prerequisite. It does not say what happens when no contact matches the phone, which is the main behavioral gap.
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?
Four short, front-loaded sentences with no filler; the lookup key leads. The 'Read-only' clause mildly restates readOnlyHint, a minor redundancy.
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 one-parameter lookup with no output schema, disclosing which fields come back and which are excluded is the right compensation. Only the no-match/multiple-match outcome 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 coverage is 0%, so the description must carry parameter meaning; it adds only that an exact, already-known phone is expected (as opposed to a search). Format normalization or exactness expectations beyond the schema's pattern/length constraints are not addressed.
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 plus the lookup key: 'Read one contact using its known phone.' That key implicitly separates it from constructiononline_get_contact and constructiononline_get_contact_by_email, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'using its known phone' plus 'requires customer API access' establishes the precondition for selecting this tool over the ID- or email-based lookups. It gives clear context but no explicit when-not or fallback guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one opportunity using its known id. Returns selected operational fields. Notes, permissions, attachment data and unrelated personal or payroll fields are omitted. Read-only; requires customer API access.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description goes beyond them by disclosing data minimization (notes, permissions, attachments, personal/payroll fields are omitted) and the customer API access requirement, which are real behavioral facts an agent could not infer from structured fields.
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?
Four short, front-loaded sentences covering purpose, return scope, exclusions and access constraint; nothing is redundant. It stops just short of a 5 because the phrasings are terse fragments rather than a tightly unified statement.
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 single-parameter read tool with no output schema, the description gives the caller what matters: what is returned at a coarse level, what is deliberately withheld, and that customer API access is required. Return structure specifics are the only gap, and no output schema exists to cover them.
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?
Only one parameter with 0% schema description coverage, so the description must carry meaning. "its known id" clarifies that the argument is an existing opportunity identifier rather than a name or filter, but adds no format, range, or lookup guidance beyond that, so compensation is partial.
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 (Read) and resource (one opportunity) plus the selection mechanism (its known id). The sibling tools all target different resources (contact, project, schedule), so no disambiguation is needed, though the description never explicitly contrasts itself with any of 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?
"using its known id" implies the precondition that the caller already has an opportunity id, which mildly rules out search-style usage. However, it never states when to prefer this over a listing/search tool or what to do when the id is unknown, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one project using its known id. Returns selected operational fields. Notes, permissions, attachment data and unrelated personal or payroll fields are omitted. Read-only; requires customer API access.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive semantics, so the description earns credit for added context: it discloses the required customer API access and enumerates what is omitted (notes, permissions, attachments, payroll fields). It stops short of describing response shape or error behavior, but adds real value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action and resource, then return scope and access requirements. No filler or repetition.
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 partly takes on return-value disclosure by stating selected operational fields are returned and listing omitted categories, and it flags the auth prerequisite. That is close to complete for a simple single-id read, though the exact field set remains unspecified.
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 single parameter has 0% schema description coverage, so the description must carry the meaning. 'using its known id' confirms it identifies a specific project, but says nothing about type constraints or format beyond that, leaving some compensation gap.
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 ('Read one project') plus the lookup key, which clearly separates it from sibling gets for contact, opportunity, and schedule. It doesn't explicitly name a sibling, but the resource distinction is unambiguous.
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?
'using its known id' implies the tool is for the case where the id is already in hand, which is a useful usage signal. However, there is no explicit statement about when to prefer this over search/list alternatives or what to do when the id is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one schedule using its known id. Returns selected operational fields. Notes, permissions, attachment data and unrelated personal or payroll fields are omitted. Read-only; requires customer API access.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, and non-destructive behavior, so the description's extra details about omitted fields and required customer API access add useful context. It does not fully describe the returned operational fields, but it improves transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core action, and every sentence adds relevant information about scope, omissions, or access requirements. There is no unnecessary wording.
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 single-record getter with rich annotations and no output schema, the description provides enough context about return-field selection and access needs. It could be slightly more complete by describing the expected response shape or id source, but it is adequate.
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 description mentions using a 'known id', which identifies the parameter as a schedule identifier, but it does not explain where to get that id or add format details. With 0% schema description coverage, it only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Read one schedule using its known id.' It clearly distinguishes this as a single-schedule read tool, and the sibling tools are for different resources, so no further sibling differentiation is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates the tool requires a known schedule id and is read-only with customer API access. It does not explicitly say when not to use it or how to obtain the id, but the usage context is still clear for a single-resource getter.
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.
constructiononline_get_contactconstructiononline_get_contact_by_emailconstructiononline_get_contact_by_phoneconstructiononline_get_opportunityconstructiononline_get_projectconstructiononline_get_scheduleLook up people, groups, service rosters, songs, follow-up flows and giving in Elvanto.
CRM, drive, email and meetings in one system of record: search, read and update your records.
Look up contacts, invoices, vouchers, orders, bank transactions and parts, and create drafts.
Query Method CRM customers, leads, activities and invoices; create and update records.
Add one secure layer between your agents and this server.