Builder Prime MCP by usefulapi

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds real information beyond the destructiveHint annotation: the write is immediate and triggers vendor notifications, which matters for a non-idempotent mutation. It still doesn't say whether the created meeting can be rolled back or what identifier comes back, so not a 5.

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 front-loaded sentences with no filler; the side-effect warning sits where an agent will see it before composing arguments. 'meetings.create required' is terse jargon that costs a little clarity for its brevity.

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 7-parameter destructive mutation with no output schema and only 43% schema coverage, the description covers side effects and preconditions but omits what the call returns (meeting id?) and how to resolve meetingTypeId or clientOpportunityId. Adequate, not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 43%, below half, so the description needs to compensate — it doesn't. It names 'dates, timezone, attendee and type', but timezone is not a parameter at all (dates are epoch milliseconds per the schema) and clientOpportunityId, title and meetingTypeId receive no explanation, leaving several required fields unexplained in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a meeting') plus the scope ('for a client opportunity'), which cleanly separates it from builderprime_update_meeting and the project siblings. An agent can identify the operation without inspecting 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?

'Confirm dates, timezone, attendee and type before calling' gives a concrete pre-flight checklist, and 'meetings.create required' signals a permission prerequisite. It stops short of naming when not to use this versus builderprime_update_meeting, so it lands just below the top mark.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes beyond the destructiveHint annotation by disclosing immediate execution and possible vendor workflow side effects, plus the 'projects.create' permission requirement. It stops short of describing failure behavior or irreversibility, so not a 5.

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 scope, then permission, confirmation, and side-effect notes. No wasted text.

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 destructive mutation with no output schema, it covers permissions, user confirmation, and downstream effects. The remaining gap is the undocumented parameter semantics, which the description does not backfill.

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 only 33% across 6 parameters with nested objects, and the description adds no meaning for projectStatus, estimatedValue, projectName, or the employee-reference objects. It only alludes to clientOpportunityId via 'existing client opportunity'.

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 ('Create a project') plus its required parent ('attached to an existing client opportunity'), which cleanly separates it from the sibling read/update/list project tools.

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 implies the prerequisite (an existing client opportunity) and adds a confirmation workflow ('Show the exact fields to the user before calling'), but it never names alternatives or says when not to use it versus update_project or get_project.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely useful context beyond annotations by naming the required permission scope (employees.read), which tells the agent about auth failure modes. It does not cover behavior for missing/not-found IDs, but the permission note is a real value-add.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short clauses, front-loaded with the action and scoping, then the permission requirement. Nothing is wasted, though the phrasing is telegraphic rather than fully explanatory.

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-param read tool with no output schema, the description covers purpose and auth. However, it omits what the ID refers to and gives no sense of the returned employee shape, which matters given zero schema description coverage.

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% and the single parameter 'id' (integer, >0) has no description anywhere. The description says 'one employee' but never clarifies that 'id' is the employee identifier, leaving the agent to infer it.

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 employee'), and 'one' implicitly contrasts with the sibling builderprime_list_employees. The distinction is not made explicit, but an agent can tell it's a single-record fetch.

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 word 'one' implies this is the single-record counterpart to builderprime_list_employees, but the description never names that alternative or says when to prefer it over a list/search. Usage is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the safety profile is covered structurally. The description adds the required permission scope ("requires meetings.read"), which is genuine value beyond annotations, but says nothing about return shape or behavior when the ID does not exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short clauses with no filler, and the action is front-loaded ahead of the permission requirement. It is efficient, though it borders on under-specification rather than true density.

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 readOnlyHint and no output schema, the definition covers the core action and the auth prerequisite. It omits what is returned and the not-found behavior, leaving a modest but real gap.

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?

There is one parameter with 0% schema description coverage, so the schema offers no meaning for "id" beyond its type. The description only implies identification by reading "one meeting" and never states that the parameter is the meeting identifier.

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 meeting"), and the singular "one" distinguishes it from the sibling list_meetings. It does not explicitly differentiate from get_meeting_result or get_meeting_type, 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 "Read one meeting" implies the tool is for retrieving a single record by identifier, which is adequate implied usage. There is no explicit when-to-use vs. when-not guidance or named alternatives such as list_meetings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description's main added value is the required scope 'meetingresults.read', which is genuine context an agent needs for auth. It says nothing about behavior on a missing/invalid id or about error responses.

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 compact sentence, front-loaded with the action and resource, with the permission requirement appended. Nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple annotated read with no output schema, the safety profile and permission scope are covered, but the ambiguity of the sole parameter's meaning is a real gap for an agent deciding what to pass.

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?

There is one required parameter ('id') with 0% schema description coverage, so the description carries the full burden and doesn't meet it: it never states whether 'id' is the meeting result's id or a parent meeting's id, nor any format constraints.

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?

Specific verb and resource ('Read one meeting result') with the singular scope distinguishing it from builderprime_list_meeting_results. It does not, however, name the sibling list tool or clarify how a 'meeting result' differs from a meeting.

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 'Read one' implies single-record lookup as opposed to listing, but no explicit when-to-use or when-not guidance is given, and no alternative like builderprime_list_meeting_results or builderprime_get_meeting is named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely new information not in structured data: the required permission scope 'meetingtypes.read', which tells the agent about auth prerequisites. It doesn't describe the return payload, but with no output schema that's a minor gap for a simple lookup.

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?

One compact sentence with the purpose front-loaded and the permission requirement appended. Zero waste, no 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 single-record read with readOnlyHint set, the description covers purpose and auth. It omits any indication of what a meeting type contains or how the id is sourced, but the tool's simplicity keeps the gap moderate.

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%, so the description must compensate for the single 'id' parameter, but it only says 'one meeting type' without clarifying that the id is a meeting-type identifier, its format, or where to obtain it. The schema alone gives type and range; the description adds almost nothing.

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 meeting type'), and 'one' distinguishes it from the sibling builderprime_list_meeting_types without naming it explicitly. An agent can infer the single-record nature, though naming the list sibling would have removed all doubt.

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?

'Read one' implies the use case is fetching a single type by id, versus the list sibling for enumerating. However, no explicit when-to-use statement or alternative is named, so the routing signal is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, but the description adds a real behavioral fact beyond them: the required permission scope 'projects.read'. It also discloses which fields come back, which matters since there is no output schema. Minor gap: no statement about behavior for a missing/invalid project id.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with no filler – action and payload first, the permission requirement second. 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?

For a simple single-entity read with no output schema, the description covers purpose, returned fields, and auth scope. The only real omission is any guidance on the single required parameter and on not-found behavior.

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?

There is exactly one parameter and it is completely undocumented: schema coverage is 0% and the description never mentions project_id, its integer type, or where to obtain it. Even for an obvious id field, this leaves the only input entirely to inference.

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 ('Read') and resource ('one project'), plus enumerates the notable returned fields (customer/status/value) so the agent knows this is a full-record fetch. It's implicitly distinct from builderprime_list_projects via 'one project', though it never names the 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?

The singular 'one project' hints at the read-one-vs-list distinction, and 'Requires projects.read' gives a precondition, but there is no explicit when-to-use/when-not or reference to builderprime_list_projects or builderprime_update_project as alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely new behavioral context the annotations do not: the required employees.read scope and the zero-based pagination convention, both of which affect whether a call succeeds and how to iterate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with purpose and permission, no filler. The 'limit max100' clause is redundant with the schema's maximum, which is the only wasted element.

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?

There is no output schema, so the description should say something about what a page of employees contains or how to detect the last page. It covers auth and pagination basics but leaves the return shape and end-of-list behavior entirely undocumented for a list tool.

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%, so the description carries the burden for both params. It supplies the important non-obvious fact that pagination is zero-based, but 'limit max100' merely restates the schema's maximum:100, and neither param's effect on results (e.g., what a page contains, defaults) is explained beyond that.

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 employees'), which cleanly separates it from the singular builderprime_get_employee sibling. It does not explicitly name that sibling or describe the scope of the list, but the list-vs-get distinction is clear enough to select correctly.

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 permission note ('requires employees.read') implies this is the collection-level read path, but the description never says when to use this versus builderprime_get_employee for a single record, nor any filtering or exclusion guidance. Usage is inferable from the name only.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds genuinely new context by naming the required permission scope (meetingresults.read) and the pagination convention. It stops short of saying what a page contains or how many pages typically exist, so it is not a full behavioral picture.

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?

One compact sentence with the permission prerequisite and pagination caveat front-loaded. No filler, nothing to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read tool with annotations and no output schema, the essentials for calling it are present, but there is no indication of what a meeting-result record looks like or how results are ordered, which an agent forming a request might want given the absence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden for both parameters. It clarifies that page is zero-based and that limit caps at 100, but 'max100' and the zero base largely restate the schema's default 0 and maximum 100 rather than adding format or behavior detail.

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 ('meeting-results'), and the name/title pair makes it distinguishable from the singular builderprime_get_meeting_result sibling. It doesn't explicitly say how it differs from the other list_* tools, but for a simple collection read the purpose 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?

Usage is only implied by 'Read' and the pagination note; there is no explicit guidance on when to use this versus builderprime_get_meeting_result or builderprime_list_meetings. It does state the required permission (meetingresults.read), which tells the agent a prerequisite but not a selection criterion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=true, and the description adds the non-obvious operational facts: the required 'meetings.read' permission scope, zero-based paging and a hard limit cap of 100. It does not say what ordering results come back in or how to detect the last page, which with no output schema would be useful.

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 packs the scope, permission requirement and pagination constraints with no filler. Every clause carries information an agent needs before calling.

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?

Given six parameters and no output schema, the description supplies the essentials: date-range requirement and units, auth scope, and pagination behavior. The only shortfall is silence on the two optional filter parameters and result ordering.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 33% schema coverage the description must compensate, and it does cover page and limit semantics and reinforces the epoch-milliseconds format. However employee_id and opportunity_id are filtering parameters never explained in either schema or description, leaving a real 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?

Specific verb ('Read') plus resource ('meetings') plus a scoping qualifier ('beginning in a required date range'), which disambiguates it from sibling get_meeting and clarifies that filtering is on start time, not overlap. It does not explicitly name the sibling it contrasts with, so it stops short of 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?

Usage is implied by the collection-vs-single distinction (list_meetings vs get_meeting), but the description never states when to prefer this over get_meeting or how to page through results. No exclusions or prerequisites beyond the permission scope.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the auth scope requirement and the zero-based pagination/max-limit constraint, which are genuine additions, but it says nothing about result size, ordering, or error behavior on out-of-range pages.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short clauses, zero filler, and the pagination constraint is front-loaded after the access requirement. The telegraphic style is efficient, though slightly terse for an unfamiliar reader.

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 two-param read tool with readOnlyHint covering safety, this is close to sufficient. But with no output schema, the description gives no hint of what a 'meeting type' record contains or how results are returned, leaving a modest gap.

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%, so the description carries the burden and does address both parameters: 'page' is zero-based and 'limit' caps at 100. It omits the default limit of 25 that the schema declares, but the key semantics are supplied.

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 ('meeting-types'), making it distinguishable from the singular sibling builderprime_get_meeting_type and from list_meetings. It does not explicitly name siblings, but the list-vs-get distinction is implicit in the name/description pairing.

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?

Adds one concrete prerequisite ('requires meetingtypes.read'), which is useful context for an agent. However, it never says when to prefer this over builderprime_get_meeting_type or how it relates to builderprime_list_meetings, so usage context is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true, and the description adds real value beyond that: required scope projects.read, page 0-based indexing, and the non-obvious vendor quirk that last_modified_since silently defaults to one year ago and older dates are rejected. It stops short of describing ordering or how paging terminates.

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, each carrying distinct information (scope, paging, history limitation, return contents). Minor terseness issues ('max100', 'Response includes customer names available on projects') slightly reduce legibility.

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?

It covers the hidden truncation behavior that an agent would otherwise get wrong, but with 5 parameters at 20% schema coverage and no output schema, two filtering parameters and the response shape remain undocumented. Adequate, not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 20% (only last_modified_since is described), and the description supplements page origin and the 100 limit ceiling plus the last-modified default. However opportunity_id and project_status remain completely unexplained in both places, leaving a meaningful 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+resource (read/list projects) and the auth scope required (projects.read). It doesn't explicitly contrast with the sibling builderprime_get_project, but the plural 'projects' plus paging makes the list-vs-single distinction inferable.

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 warning that this 'is not a complete all-history report' implies when the tool is insufficient, which is useful, but no positive when-to-use guidance or explicit alternative (builderprime_get_project) is named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only supply destructiveHint=true; the description adds the essential context: required permission scope, that the change runs immediately with no enforced approval step, that a blank location is a destructive clear rather than a no-op, and the partial-date hazard. That is materially more than the annotation conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, followed by permission, execution semantics, and the destructive/hazard notes. No filler sentences; every clause carries a fact an agent needs.

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 7 params, a nested employee object, no output schema, and a destructive mutation, the description covers auth, immediacy, clearing behavior, and the date hazard. It leaves unspecified whether omitted fields are preserved and what the response contains, but overall it is sufficient to call safely.

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 43%, so the description must compensate, and it does for the riskiest parameters: it explains that location=blank clears the field and that start/end times must be cross-checked against the existing meeting before a single-ended change. meetingTypeId and title remain undocumented here, which keeps it from a 5.

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 ('Reschedule or edit') and resource ('meeting details'), which cleanly separates it from create_meeting and the get/list siblings. It does not name siblings explicitly, but the instruction to 'read the existing meeting' implicitly routes to builderprime_get_meeting.

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 concrete preconditions ('meetings.edit required') and a procedural rule: read the existing meeting before changing only one of start/end. It does not state when-not-to-use or name an alternative tool, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the destructiveHint annotation, the description explains that only supplied fields are modified, changes run immediately, status changes may trigger workflows, and no deletion/archiving occurs. This gives an agent meaningful side-effect and permission context for a mutation tool.

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 compact and front-loaded with the core action: 'Modify only supplied project fields.' Every additional clause adds relevant operational context without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema and a destructiveHint annotation, the description covers permissions, partial-update behavior, workflow side effects, and deletion exclusions. It is largely complete for correct invocation, though it does not describe error behavior or response details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%, so the description must compensate. It adds useful semantics for projectStatus ('must exactly match the account') and clarifies partial-update behavior, but does not explain project_id, projectName, estimatedValue, or the employee ID fields beyond what the schema already says.

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 uses a specific verb and resource: 'Modify only supplied project fields.' It clearly identifies this as a partial update operation on projects, distinguishing it from create/get/list siblings even without naming 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?

It gives clear usage context: projects.edit permission is required, status names must match the account, and deletion/archiving is excluded. It does not explicitly name alternative sibling tools such as get_project or create_project, which keeps it from a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.