trimble-connect-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool targets a distinct resource-action pair (e.g., list_projects vs get_project, upload_file vs upload_new_version). Even closely related tools like tc_list_folder and tc_folder_tree are explicitly differentiated by output format (raw items vs text tree), and permission tools have clear semantics (get, merge, replace, remove). No two tools appear to do the same thing.
Naming Consistency4/5All tools share the `tc_` prefix and mostly follow a verb_noun pattern (get_project, create_folder, list_groups). A few exceptions like tc_folder_tree, tc_auth_status, and tc_write_status use noun-first naming, but the pattern remains predictable and readable.
Tool Count2/5With 40 tools, the surface is very large. While the domain is broad, many tools are granular (e.g., 7 group tools, 6 permission tools) and there are two raw API escape hatches (tc_api_get/write) that add complexity. This exceeds the typical well-scoped range and could overwhelm agents.
Completeness5/5The tool set provides comprehensive coverage of the Trimble Connect CDE: auth, project management, folder/file operations (create, read, update, delete, copy, move, versioning), permissions, groups, members, and search. Raw API tools fill any remaining gaps, so there are no obvious dead ends.
Average 4.6/5 across 40 of 40 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- 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.jsonto 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 indicate readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not need to cover safety. It adds the return shape and a note on group purpose, but does not disclose behaviors like pagination, ordering, or permission requirements. Given strong annotations, this is adequate 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args and Returns sections, making it easy to parse. The sentence about folder permissions is extra context but not entirely unnecessary. It remains concise and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema exists, so the description need not explain return values in depth. However, it lacks any note on error handling, required permissions, or behavior for invalid project IDs. It is sufficient for a basic list operation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description merely repeats 'project_id: Project ID' without adding format, source, or validation details. The description fails to compensate for the lack of schema descriptions, providing only the parameter name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'List the user groups of a project,' using a specific verb and resource. This distinguishes it from siblings like tc_list_project_members or tc_list_group_users. The added context about groups being used for folder permissions further clarifies the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives some context about why groups are used but does not explicitly state when to use this tool versus alternatives like tc_list_group_users or tc_list_project_roles. There is no mention of when not to use it, leaving usage implied rather than explicit.
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 indicate readOnlyHint=true and destructiveHint=false. The description adds value by specifying the return format (a dict with 'roles' as a list of strings) and the typical role values (ADMIN and USER), which aids the agent in understanding what to expect beyond the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear structure that includes a one-line purpose, an Args section, and a Returns line. Every sentence earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter and a clear return type. With rich annotations (readOnly, idempotent, non-destructive) and an output schema present, the description covers the essential aspects. It lacks only deeper context like error cases or prerequisites, but these are less critical for such a straightforward read-only operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only restates 'project_id: Project ID' without adding any meaning beyond the parameter name and type. No details about format, constraints, or examples are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the roles available in a project' with a specific verb and resource. It distinguishes from sibling tools like tc_list_project_members by focusing on roles (typically ADMIN and USER) rather than members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need project roles) but does not explicitly compare it to alternatives or state exclusions. Sibling tools include tc_get_project and tc_list_project_members, but no guidance is provided on how to choose between them.
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 indicate a write operation (readOnlyHint=false) and non-destructive nature (destructiveHint=false). The description adds value by disclosing the TC_ENABLE_WRITE=1 requirement and the return format with {"renamed": true}, which are not in annotations. This provides meaningful behavioral context beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, with four short sections: purpose, requirement, args, and return. It front-loads the main verb and includes no filler or irrelevant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (three required string parameters, no enums) and the presence of an output schema, the description is largely complete. It covers the core purpose, the write requirement, and the return signature. It doesn't address error conditions, but this is minor for a simple rename operation with available annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. However, the Args section merely restates the parameter names ('Project ID', 'Group ID', 'New group name') without any additional details such as where to obtain the IDs, uniqueness constraints, or format requirements. This fails to add meaning beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Rename a project group.' which is a specific verb+resource statement that clearly distinguishes this tool from siblings like tc_rename_item, tc_create_group, and tc_delete_group. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (renaming a project group) and states a prerequisite (TC_ENABLE_WRITE=1). It does not explicitly mention alternatives or exclusions, but the tool name and description make the intended use unambiguous, so it meets the 'clear context' bar.
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 indicate a write operation (readOnlyHint=false), and the description adds valuable operational context: the TC_ENABLE_WRITE requirement and the API behavior of ignoring new names when a new parent is sent. This complements rather than contradicts the annotations, though it does not cover error cases or atomicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: an opening purpose, a requirement line, a behavioral note, a concise Args list, and a Returns line. Every sentence serves a purpose with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the essential operational details: the write flag, the rename/move separation, all parameters, and a return value sketch. It omits edge-case behavior (e.g., errors, conflicts), but the output schema and sibling context fill most gaps, making it sufficiently complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the Args section provides basic meanings for each parameter (e.g., 'Folder or file ID' for item_id, default for item_type). This adds some value but is largely tautological, merely restating field names without deeper detail like ID formats or type constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Rename a folder or a file' with a specific verb and resource, clearly distinguishing it from sibling tools like tc_move_item and tc_copy_file. The title and tool name align, and the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: requires TC_ENABLE_WRITE=1 and explicitly warns that renaming and moving must be separate calls, which differentiates it from tc_move_item. However, it does not explicitly name alternatives or state when not to use the tool beyond this separation constraint.
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, openWorldHint, idempotentHint, and destructiveHint=false, covering safety. The description adds valuable behavioral context: the exact return structure, the meaning of 'origin' as API base URL, and the one-region-per-project constraint, which are not just repeated from 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a return format snippet, and a clarifying note about region resolution. Every sentence adds value without redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema, the description is complete. It explains what the tool returns, the meaning of the fields, and the relationship to other tools (auto-resolution), fully covering the necessary context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and schema coverage is 100% (empty properties). Baseline for 0 params is 4, and the description does not need to add parameter details. It correctly omits parameter information entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List Trimble Connect regional servers' with examples of regions. This is a specific verb+resource combination that distinguishes it from other list tools like tc_list_projects or tc_list_project_roles, which operate on 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context by noting 'other tools resolve the region automatically from project_id,' suggesting this tool is not needed for everyday operations but does not explicitly state when to use it or when to avoid it. This is implied rather than explicit 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?
Beyond the annotations (readOnlyHint=false), the description adds the TC_ENABLE_WRITE=1 requirement and the return format {'created': true}, providing useful behavioral context not covered by structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose, prerequisite, args, and return value are each covered in a clear, front-loaded manner with no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation, it covers the essential aspects: purpose, prerequisite, args, and return. It does not detail error scenarios or side effects, but given the tool's simplicity and the output schema mention, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description explains both parameters with examples (e.g., group name), fully compensating for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States 'Create a user group in a project' with a specific verb (create) and resource (user group), clearly distinguishing it from siblings like tc_list_groups, tc_rename_group, and tc_delete_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for creating a user group and mentions the prerequisite TC_ENABLE_WRITE=1. However, it does not explicitly discuss when not to use this tool or mention alternatives, but the purpose itself implies the usage.
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. The description adds that project_id resolves the region and outlines the return structure, which goes beyond annotations and clarifies behavior. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with Args and Returns sections; every sentence provides necessary information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with two parameters and an output schema, the description covers purpose, parameter semantics, and return format. It omits pagination or error details, but given the simplicity and annotation coverage, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by defining both parameters: project_id as 'Project ID (resolves the region)' and group_id as 'Group ID from tc_list_groups'. This gives meaningful context beyond the raw schema's generic string types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the members of a project group' with a specific verb and resource, distinguishing it from sibling tools like tc_list_groups (lists groups) and tc_list_project_members (lists project members).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a prerequisite by noting group_id comes from tc_list_groups, and explains that project_id resolves the region. However, it does not explicitly contrast with alternative tools like tc_list_project_members, so it doesn't fully guide when-not-to-use.
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?
Beyond annotations (destructiveHint=true), the description discloses the confirmation safety gate and the TC_ENABLE_WRITE requirement, plus the return format. It does not mention reversibility or partial failure, but enough context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a front-loaded purpose, followed by requirements, arguments, and return type. Every line provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive write operation, the description covers purpose, prerequisites, all parameters, and return format. It lacks details on error handling or transaction behavior, but overall it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by defining each argument: project_id, group_id, user_ids, and confirm as a safety gate. The meaning of user_ids ('Member ids to remove') is clear, and confirm's role is explicitly stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first line 'Remove members from a group (they stay in the project)' uses a specific verb and resource, clearly stating the action and scope. It distinguishes from sibling tools like tc_remove_project_user by clarifying the membership stays in the project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: removing members from a group while retaining project membership, and states prerequisites (TC_ENABLE_WRITE=1 and confirm=true). It does not explicitly name alternative tools, but the context makes usage unambiguous.
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 meaningful behavioral context beyond the annotations by stating the TC_ENABLE_WRITE=1 requirement and the precondition that users must already be project members. It also describes the return shape, which is not in annotations. No contradictions 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. It uses concise sections for requirements, prerequisites, arguments, and return value, with no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no enums/nested objects) and the presence of an output schema, the description is complete. It includes preconditions, environment requirements, parameter semantics, and return format, covering all essential usage aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by explaining each parameter. It clearly identifies project_id and group_id as IDs, and user_ids as 'Member ids from tc_list_project_members', which provides valuable source context beyond the schema's bare property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add project members to a group' with a specific verb and resource. This clearly differentiates it from sibling tools like tc_add_project_user (adds users to a project) and tc_remove_group_users (removes users from a group).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it requires TC_ENABLE_WRITE=1 and specifies that users must already be project members, referencing tc_add_project_user for the prerequisite. It does not explicitly list alternative tools for removal, but the context is strong.
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 (destructiveHint, readOnlyHint), the description discloses a critical side effect: 'any folder permission granted to this group disappears with it.' It also explains the safety gate (confirm must be true) and the environment flag requirement, adding significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a purpose line, a warning, requirements, parameter explanations, and a return format. Every sentence adds value, with no fluff or repetition of what the schema already shows.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation, the description covers what is deleted, the side effect on permissions, required conditions, parameter semantics, and the expected return value. This is complete enough for an AI agent to execute correctly with minimal ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions, so the description must compensate. It provides meaningful context for 'confirm' (must be true, safety gate) and identifies project_id/group_id as IDs, though it doesn't explain them beyond that. This is adequate but not rich, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a project group' with a specific verb and resource, and distinguishes itself from sibling tools like tc_create_group, tc_rename_group, and tc_list_groups. The destructive consequence is also highlighted, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this tool is for deleting a project group and includes prerequisites (TC_ENABLE_WRITE=1, confirm=true). It does not explicitly name alternatives or say when not to use it, but the context is sufficient given the unambiguous purpose.
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=false. The description adds value by noting it returns 'the raw file JSON from the API', restricts to the 'latest version', and explains that project_id resolves the region. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose, args, return. Every sentence provides necessary information without repeating annotation data or schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only metadata operation, the description fully covers what the tool does, the two required parameters, and the return format. The output schema exists to provide field details, and annotations cover safety, so the tool is adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining both parameters: project_id is the project the file belongs to and resolves the region, while file_id is identified as coming from tc_list_folder. This goes beyond the bare schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get metadata of a file (latest version): name, size, revision, dates,' which is a specific verb plus resource. The 'latest version' qualifier distinguishes it from sibling tools like tc_list_file_versions and tc_download_file, making the tool's purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear invocation context: project_id resolves the region, and file_id comes from tc_list_folder. However, it does not explicitly state when to prefer this over tc_download_file or tc_list_file_versions, so it lacks an explicit exclusion.
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, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds value by specifying the return contents ('complete project JSON including rootId, license info, counts and settings') and noting it is the raw API object, which goes beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three lines: a clear purpose sentence, an args line, and a returns line. No fluff; every sentence earns its place with useful, non-redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with robust annotations and an output schema, the description fully conveys the tool's function and return value. The cross-reference to tc_list_projects for the ID ensures the agent knows how to obtain the required parameter, making this complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides actionable semantics by stating that project_id comes from tc_list_projects, telling the agent where to source the ID. However, it doesn't specify format or constraints beyond the schema's string type, a minor gap given only one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get full details of one project (raw API object)', which clearly identifies the action (get), resource (project), and scope (full details of one). This distinguishes it from siblings like tc_list_projects (which lists projects) and tc_get_file (which gets files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs the agent to obtain project_id from tc_list_projects, establishing a clear prerequisite workflow. However, it does not explicitly name alternative tools or state when not to use this tool, so it has clear context but no explicit exclusions.
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, covering safety. The description adds the return format (count and versions with fields) and notes fields are 'as provided by the API,' giving extra behavioral context 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at five lines, structured with Args and Returns sections. Every sentence contributes value—purpose, parameter definitions, and return shape—without redundant or irrelevant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation, the description covers the essential aspects: purpose, required parameters, and return object structure. Annotations cover the safety profile, and the output schema (if present) would handle further details. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by explaining project_id as 'Project the file belongs to' and file_id as 'File ID.' These explanations add meaning beyond the bare property names, though they are minimal and lack examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List the version history of a file,' which is a specific verb + resource combination. It clearly distinguishes from sibling tools like tc_get_file and tc_download_file by focusing on version history rather than content retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context: you use this when you need the version history of a file. It does not explicitly state when not to use it or name alternatives, but no overlapping sibling exists for listing versions, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include idempotentHint=true and destructiveHint=false. The description adds behavioral detail by noting it frees the callback port and returns a boolean cancelled flag, which is useful context beyond the annotations. No contradiction found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line action, a two-line usage scenario, and a one-line return format. Every sentence adds value and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with no input schema properties, the description fully covers purpose, when to use, and the return value. The annotations and output schema handle remaining context, making this description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, so no parameter documentation is necessary. The description correctly omits parameter details and still conveys the tool's behavior, aligning with the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Abort' and identifies the resource: 'a browser sign-in that is still waiting' and 'free the callback port'. This clearly distinguishes it from sibling tools like tc_login (which initiates sign-in) and tc_auth_status (which checks status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use when a tc_login attempt was abandoned (wrong account, browser closed) and the local callback listener should stop before starting a new login.' It provides clear context and sequence, though it does not explicitly list when not to use or alternative tools.
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 (readOnlyHint=false, destructiveHint=false, etc.), the description adds valuable behavioral context: the environment variable requirement, the PENDING status until the invitee opens the project, and the notify flag controlling email sending. It also discloses the return shape with {'invited': true}, giving a clear picture of side effects and outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence summary, a condition line, a labeled Args block, and a return note. Every sentence adds distinct value, with no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and an output schema, the description covers all necessary aspects: purpose, prerequisite, parameter semantics, side effects (PENDING status), and return value. The output schema existence means details of the return object are not required, and the description still gives the key field {'invited': true}, making it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates fully by explicitly documenting every parameter: project_id, email, role (with default and allowed values, plus cross-reference to tc_list_project_roles), and notify (with default and effect). This adds meaning well beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Invite a user to a project by email,' which states the core action, resource, and method. This clearly differentiates it from sibling tools like tc_update_project_user and tc_remove_project_user by indicating the specific operation of adding/inviting a new member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite (TC_ENABLE_WRITE=1) and references tc_list_project_roles as a check for valid role values. However, it does not explicitly state when to use this tool versus alternatives, such as tc_update_project_user, or mention scenarios where this tool should not be used, leaving usage guidance mostly implied.
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. The description adds meaningful context by stating it writes only to the local download folder, defaulting save_dir to TC_DOWNLOAD_DIR, and defaulting file_name to the metadata name. It does not contradict annotations; rather, it clarifies the local-side write behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then uses an Args block to compactly document parameters and a Returns line for output. Every sentence adds information; there is no fluff. The structured format makes it easy for an agent to scan quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with an output schema, the description is fully complete: it explains all parameters, defaults, side effects, and return format. It even notes provenance of parameters from sibling tools. No important behavior is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for explaining the 5 parameters. It does so thoroughly: project_id, file_id, version_id (with source tc_list_file_versions and default latest), file_name (with default), and save_dir (with default TC_DOWNLOAD_DIR). This goes well beyond the schema's bare type/title information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Download a file from Trimble Connect to the local disk.' This clearly distinguishes it from siblings like tc_get_file (which likely retrieves content/metadata without saving to disk) and tc_upload_file (which pushes data). The read-only and local-write clarification further disambiguates its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it downloads files to local disk and notes the Trimble side is read-only. It also references where to obtain parameter values (file_id from tc_list_folder, version_id from tc_list_file_versions), implicitly guiding use. However, it does not explicitly mention when to prefer this over alternatives like tc_get_file or tc_api_get, so it falls short of full explicit when/when-not 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 readOnlyHint=true and destructiveHint=false, so no contradiction. The description adds valuable behavioral context: project_id is used to resolve the region, folder_id omission triggers root listing, and the return payload shape is disclosed, including item types and fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a short Args section, and a Returns block with a concrete JSON example. Every sentence adds value and no extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only list operation with two parameters and an output schema; the description covers purpose, parameter semantics, return structure, and how to navigate from results. It is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It explains project_id's role in region resolution and folder_id's role including the optional/root behavior, adding meaning far beyond the bare schema titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'List the contents (subfolders and files) of one folder.' It also distinguishes itself from siblings like tc_folder_tree or tc_get_file by focusing on listing a single folder's immediate children, and it clarifies that omitting folder_id returns the root folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use the tool: list a single folder's contents, and provides guidance to 'Use item ids to descend into subfolders or fetch file details.' It does not explicitly exclude alternatives like tc_folder_tree for full-tree traversal, but the one-folder scope is unambiguous.
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. The description adds valuable behavioral context: it defines the output shape, the meaning of status values, the default for include_removed, and notes that member ids are what folder-permission tools expect. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence summary, then organizes parameter explanations and return format in clear Args/Returns sections. Every sentence adds needed information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with an output schema present, the description covers all necessary context: parameters, defaults, output shape, and cross-tool compatibility. Given the sibling set, this is a complete and self-contained description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are 0% covered, so the description must fully explain parameters. It does: project_id is sourced from tc_list_projects, include_removed controls whether REMOVED users appear and defaults to False, and group_id filters to a specific group. This adds meaning entirely beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 members (users) of a project with their role and status.' This clearly differentiates it from sibling tools like tc_list_group_users and tc_list_project_roles by specifying the subject is project members and includes role/status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: project_id comes from tc_list_projects, group_id is optional and references tc_list_groups, and include_removed changes the result set. It does not explicitly state when not to use this tool, but the provenance and filtering guidance make 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 clear. The description adds behavioral insights: return format '{count, results}', that results are 'raw search results from the API', and that omitting project_id means searching 'all regions'. This goes beyond the annotations and helps the agent anticipate output and regional behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a one-sentence overview followed by Args and Returns sections. Every sentence adds value and there is no filler. The main purpose is front-loaded, and the parameter details are easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with optional project scoping and multi-region behavior, the description is complete. It explains the input semantics, return format, and regional behavior. The output schema is present, so return value details are adequately covered. With safe/hint annotations, no additional behavioral disclosure is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It explains both parameters: 'query' as 'Search text (e.g. a file name or keyword)' and 'project_id' as an optional limiter with performance and scope implications. This adds meaning well beyond the bare schema names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search Trimble Connect for files, folders, todos etc. by text.' This provides a specific verb ('Search'), a resource ('Trimble Connect'), and a scope (files, folders, todos, etc. by text). It distinguishes itself from sibling tools like tc_get_file or tc_list_folder by emphasizing text-based search across multiple item 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage guidance for the optional project_id parameter: 'limit the search to one project (faster, searches only that project's region). Omit to search all regions.' This tells when to include or omit the parameter and explains the trade-off, but it does not explicitly mention alternatives among sibling tools. Still, it gives clear context for effective use.
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 annotations, the description discloses that the operation walks the tree, recreates folders, copies files one by one, can be slow, and may be truncated by max_items. It also mentions the requires write flag and returns an errors field, providing substantial insight into behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured: core action, then caveats, then args, then return value. Each sentence provides valuable information without redundancy, though it could be tightened by moving the args list to a more compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the provided output schema, the description covers all necessary context: operation mechanics, performance caveats, configuration requirement, parameter semantics, and return value structure. It is complete enough for an agent to decide when to use it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter. It clarifies target_parent_folder_id as 'Folder that will contain the copy,' new_name defaults to the source name, and max_items as a safety cap—meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Copy a folder and everything inside it to another location' with a specific verb and resource, clearly distinguishing it from sibling tools like tc_copy_file. The title 'Copy folder (recursive)' reinforces the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool by noting that Trimble Connect lacks a server-side copy endpoint, so a manual walk is needed. It warns about slowness for large trees and mentions the max_items cap and the TC_ENABLE_WRITE requirement, but does not explicitly name alternative tools.
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?
While annotations already mark as destructive/write, the description adds valuable behavioral context: removal removes entries entirely, fallback to parent grants, and the confirm safety gate. It does not mention irreversibility explicitly but the destructive hint covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Highly structured and efficient: opening sentence gives the core action, followed by behavior notes, args list, and return format. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters, annotations, and no formal output schema, the description is remarkably complete. It covers prerequisites, alternatives, parameter meanings, and return shape, leaving little ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It names every parameter with a brief meaning, adds that confirm is a safety gate, and clarifies item_type defaults. This goes beyond the schema's bare types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes users/groups from an ACL entirely, with specific scope (folder/file). It distinguishes from related tools by explicitly naming tc_grant_permissions as the alternative for blocking access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: explains fallback behavior, names alternative for blocking, and states the hard requirements (TC_ENABLE_WRITE=1 and confirm=true). This gives the agent clear decision-making 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 indicate a non-idempotent write (readOnlyHint=false, idempotentHint=false). The description adds key behavioral details: fails on duplicate file name, requires TC_ENABLE_WRITE=1, and provides a return structure. These go beyond the annotations and help the agent anticipate outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: purpose sentence, failure note, requirement, args, returns. Every line contributes essential information; there is no redundant repetition of schema titles. While the Args list adds length, it replaces missing schema descriptions, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with four parameters and no schema descriptions, the description covers all aspects needed for invocation: when to use, when not to, prerequisites, parameter semantics, and return format. It also contrasts with the closest sibling tool. No critical gaps remain for successful agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the Args section fully compensates: each parameter is explained with purpose and sources (e.g., folder_id from tc_list_folder/tc_folder_tree). The optional name parameter's default behavior is also specified. This is exemplary compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource+scope: 'Upload a NEW file from the local disk into a Trimble Connect folder.' Explicitly distinguishes from sibling tc_upload_new_version by noting it fails on duplicate names and directing to that tool for revisions. This leaves no ambiguity about the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly states when not to use it: if a file with the same name exists, use tc_upload_new_version instead. Also mentions the prerequisite TC_ENABLE_WRITE=1, which is a clear environmental condition for use. No other alternatives are discussed, but 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the environmental prerequisite (TC_ENABLE_WRITE=1), the exact return fields, and the confirm=true requirement for destructive tools, which goes beyond the structured annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a list of affected tool types, and a return value breakdown. Every sentence adds information; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description still explains the meaning of each return field and the operational context. It fully covers the tool's behavior and purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 the description doesn't need to explain parameter semantics. Baseline of 4 for no-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check whether this server may modify data in Trimble Connect.' It lists affected write operations and distinguishes itself from status checks like tc_auth_status. The verb-resource pairing is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that write tools only work when TC_ENABLE_WRITE=1, giving clear context for when to use this status tool. It also notes destructive tools require confirm=true, but it doesn't explicitly mention alternatives or exclusions, so it falls short of full usage guidance.
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?
The description discloses that the copy is server-side, requires a write-enabled environment, supports optional version and metadata, and handles name conflicts by creating a new revision instead of failing. It also notes the constraint that merge_existing cannot be combined with copy_metadata. These details go well 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a short summary followed by an args list. It avoids redundancy and includes only necessary operational details, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value and key behavioral rules, and it covers all parameters. Combined with the output schema, an agent has enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains all six parameters with concrete meaning: project_id, file_id, target_folder_id, version_id, copy_metadata, and merge_existing. It clarifies defaults (latest version) and the conflict resolution behavior, which the schema does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Copy') and resource ('one file') and specifies the destination ('another folder'). This clearly differentiates the tool from siblings like tc_copy_folder, tc_move_item, and tc_upload_new_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives operational context: it requires TC_ENABLE_WRITE=1 and enforces that source and target are in the same project. It does not explicitly name alternatives but the use case is clearly scoped to copying a single file, which implies when to use it.
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=false (write), destructiveHint=false, and idempotentHint=false. The description adds valuable context beyond these: the folder name must be unique within the parent, max 255 characters, parent_folder_id omitted means root folder, and the return format. This provides constraints and side-effect expectations not captured in 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: purpose first, then prerequisite, args, return value, and alternative. Every sentence adds value, with no redundant information. It front-loads the primary purpose and uses formatting (one line per param) for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create-folder tool, the description covers prerequisites, parameter semantics, constraints, return format, and the key alternative for larger operations. It is self-contained even though the input schema is minimal, and it references tc_write_status for extra context. No critical gaps exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the full burden of explaining parameters. It does so thoroughly: project_id resolves the region, name has length/uniqueness constraints, and parent_folder_id has a default behavior (root folder). All three parameters are semantically defined, fully compensating for the schema's minimal info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Create ONE new folder inside a parent folder,' which is a specific verb+resource and clearly states the tool's scope. It also distinguishes from sibling tool tc_create_folder_structure, noting that for a 'whole CDE tree use tc_create_folder_structure instead.' This makes the purpose unmistakable and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit prerequisite: 'Requires TC_ENABLE_WRITE=1 (see tc_write_status).' It also gives an explicit alternative for a different use case: 'For a whole CDE tree use tc_create_folder_structure instead.' This gives clear when-to-use and 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behaviors beyond the annotations: the TC_ENABLE_WRITE requirement, automatic creation of intermediate levels, the default behavior of skip_existing, and the return structure. It also notes that the call is safe to re-run, providing a nuanced behavioral trait not captured by the idempotentHint=false annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, a requirement note, a detailed Args list with examples, and a return format section. Every sentence adds value, and the layout makes it easy to scan. It is concise for the complexity it covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool with 4 parameters and a write operation. It covers prerequisites, parameter semantics, default behavior, return values, and a real-world use case. The output schema is described in text, and the annotations are complemented rather than contradicted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite a schema description coverage of 0%, the description explicitly explains every parameter in the Args section, including the format for paths, the meaning of parent_folder_id, and the use of skip_existing. This fully compensates for the lack of schema-level descriptions and adds practical examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Create a whole folder tree in one call'. It provides a concrete use case (ISO 19650 CDE) and distinguishes itself from singular folder creation tools like tc_create_folder by emphasizing bulk creation of a hierarchical structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case and a prerequisite (TC_ENABLE_WRITE=1), but does not explicitly mention alternatives or when not to use it. It implies usage for bulk folder structure creation with the phrase 'in one call', which helps differentiate from sibling tools, but lacks explicit exclusion guidance.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds substantial behavioral detail: no undo via API, Trimble Connect's soft-delete nuance, admin web-UI restore, the force flag's background deletion of the whole subtree, and the confirmation safety gate. This is far beyond the structured 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the most critical information (destructive, no undo), then details prerequisites, parameter semantics, and the return value. Every sentence earns its place—no filler—and the structured 'Args' section makes it scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive operation with several caveats: irreversibility, confirmation requirements, environment variable gate, force semantics, and background jobs. The description covers all of these, and an output schema is available for return-value details. It is complete for a high-risk tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by explaining all five parameters: project_id, item_id, confirm as a safety gate, item_type defaulting to FOLDER versus FILE, and force required for non-empty folder subtree deletion. It also notes the return shape, giving agents the semantic context missing from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object—'Delete a folder or a file'—clearly identifying the tool's operation. It distinguishes itself from sibling tools like tc_create_folder, tc_move_item, and tc_rename_item by explicitly naming the deletion scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit operational conditions: TC_ENABLE_WRITE=1, confirm=true, and the need to always show the user what will be deleted. It explains when force is required. It does not explicitly name alternative tools or state when not to use the tool, but the safety and prerequisite guidance strongly imply the intended usage context.
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?
While annotations already indicate read-only, idempotent, and non-destructive behavior, the description adds rich behavioral detail: return format, inheritance flag, id types (project user ids vs group ids), special id 'tc-groups:*', and file-specific constraints. This goes well beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with clear 'Args' and 'Returns' sections. Every sentence provides useful information, and there is no redundancy with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with an output schema, the description covers all critical behavioral aspects: return fields, id resolution, inheritance, and file limitations. It is complete enough for an agent to use the tool correctly and interpret results without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by providing the meaning of each parameter: project_id is Project ID, item_id is Folder or file ID, and item_type defaults to FOLDER or FILE. It also explains constraints on item_type (files only support READ and FULL_ACCESS), which adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Read the access control list (ACL) of a folder or file', which clearly states the verb and resource. It is well differentiated from sibling tools like tc_set_permissions, tc_grant_permissions, and tc_remove_permissions, which are write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (for reading permissions) versus modifying them. It also notes that files support only READ and FULL_ACCESS, which helps the agent know when this tool is appropriate. However, it does not explicitly mention an alternative tool for setting permissions, so it misses the full 'when-not' guidance.
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?
The description fully discloses the merge behavior: reads the current ACL, moves given subjects to the requested level, and writes the whole ACL back while preserving everyone else's permissions. It also notes the folder-only restriction for 'NO_ACCESS' and the TC_ENABLE_WRITE=1 requirement, all of which go 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: a one-line summary, a behavioral explanation, a prerequisite, then an Args list, and a Returns line. Every sentence provides necessary information, and the Args list is compact yet complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no schema descriptions, and an output schema, the description covers everything needed: the action, mechanism, prerequisites, parameter semantics, and return value shape. It provides enough detail for an AI agent to invoke it correctly without additional lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates elegantly by explaining each parameter: subject_ids with a special wildcard, level with allowed values and folder-only restriction, item_type with default, inheritance with optional behavior, and project_id/item_id as identifiers. This is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb ('Give') and resource ('users/groups a permission level on a folder or file'). The parenthetical '(safe merge)' immediately distinguishes it from siblings like tc_set_permissions and tc_remove_permissions by hinting at the merge behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the operation's context and a critical prerequisite (TC_ENABLE_WRITE=1). It also references sibling tools (tc_list_project_members, tc_list_groups) for constructing subject_ids. However, it does not explicitly say 'use this instead of tc_set_permissions' or otherwise contrast with alternatives.
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 (readOnly, idempotent), the description discloses that the tool queries every region and merges results, and that the refresh parameter re-discovers regions. These are non-obvious behavioral traits that meaningfully aid the agent. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose statement, a brief usage note, a compact Args section, and a Returns shape. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, strong annotations, and an explicit output schema, the description is complete. It covers usage context (find project ID first), behavioral behavior (cross-region merging), parameter semantics, and return structure, leaving no meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides zero parameter descriptions (0% coverage), so the description carries the full burden. It fully explains each parameter: name_filter as a case-insensitive substring and refresh as a region rediscovery flag with a default of False. This goes well beyond the schema's bare titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all Trimble Connect projects the signed-in user can access'), making its purpose unambiguous. It also distinguishes itself from sibling tools by noting it is used to find a project's ID before calling folder/file 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool to find a project ID before calling folder/file tools, providing clear when-to-use context. However, it does not explicitly name alternative tools (e.g., tc_get_project) or give when-not-to-use exclusions, so it stops short of full alignment with the highest rating.
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?
The description goes well beyond annotations by disclosing that moving a folder moves its entire subtree, permissions may change through inheritance, and the write flag is required. It also provides a sample return structure, giving the agent a clear picture of the tool's side effects and output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-organized with an Args and Returns section, and every sentence provides necessary information. It avoids redundancy and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description covers all essential aspects: prerequisites, behavior, parameters, and return value. It also explains edge cases like subtree movement and permission inheritance, making it complete for an agent's decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds significant meaning over the bare schema: it explains each parameter's role, specifies that item_type defaults to 'FOLDER' and accepts 'FOLDER'/'FILE', and clarifies which parameters are required. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear, specific verb-resource pairing: 'Move a folder or file into another folder.' It also outlines the key arguments and distinguishes this operation from sibling tools like copy or rename, making the tool's purpose immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite 'Requires TC_ENABLE_WRITE=1' and notes important behavior (moving a folder moves its whole subtree, permissions may change). While it doesn't explicitly mention alternatives, the action is clearly scoped to moving, so an agent can infer when to use it.
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?
The description adds significant behavioral context beyond the annotations: it warns "DESTRUCTIVE — they lose all access," and discloses the write-enable requirement and the confirm safety gate. This enriches the agent's understanding of consequences and prerequisites, complementing the destructiveHint and readOnlyHint annotations without 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear purpose line, requirement line, Arg list, and return value. Every sentence serves a purpose, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, output schema, annotations), the description covers all necessary aspects: purpose, usage conditions, parameter semantics, and return format. It is complete and self-sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args section that explains each parameter: project_id is the project ID, user_id is the member ID from tc_list_project_members, and confirm must be true as a safety gate. This fully compensates for the lack of schema documentation and adds cross-reference information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states "Remove a member from a project," which is a specific verb (remove) and resource (member from a project). This clearly distinguishes it from sibling tools like tc_add_project_user and tc_update_project_user, which perform different actions on project members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage conditions: "Requires TC_ENABLE_WRITE=1 AND confirm=true." It also notes the destructive nature, which implies caution. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a full 5.
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 (readOnlyHint=false), the description reveals a critical write-enable requirement (TC_ENABLE_WRITE=1) and specifies the return format as the updated member object with {'updated': true}. No contradiction with annotations; this adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a prerequisite line, a clean parameter list, and a return-value note. Every sentence adds information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description covers the required write-enable flag, parameter semantics, and return value. Combined with existing annotations and output schema, it provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), and the description fully compensates by explaining all three parameters, including the allowed values for role ('ADMIN' or 'USER') and clarifying that user_id is a member ID, not an email.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Change' with a clear resource 'project member's role' and provides an example (USER → ADMIN), making its purpose unambiguous. It distinguishes from sibling tools like tc_add_project_user or tc_remove_project_user by focusing specifically on role modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the prerequisite 'Requires TC_ENABLE_WRITE=1' and instructs that user_id should be obtained from tc_list_project_members, not the email. This gives clear context for use, though it doesn't explicitly name alternative tools or negative conditions.
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?
While annotations already mark the tool as destructive and non-read-only, the description adds valuable behavioral context: the existing file keeps its history, the new content becomes the latest revision, and confirm acts as a safety gate. It also explains the consequence of a name mismatch, going beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an introductory sentence, key behavioral notes, an arg list, and return shape. Every sentence adds value, and the arg list directly maps to schema properties without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: purpose, prerequisites, behavior, parameter semantics, and return value. It also highlights the most likely mistake (name mismatch) and the safety gate. Given the output schema exists, the description is sufficiently complete for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description fully compensates by explaining each parameter's role. It clarifies that 'name' defaults to the local file name and must match exactly, and that 'confirm' must be true. This is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads a file as a NEW VERSION of an existing file, differentiating it from merely uploading a new file (tc_upload_file). It specifies the resource (existing file in a folder) and the action (upload new content as latest revision).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (TC_ENABLE_WRITE=1, confirm=true) and a critical caveat (name must match exactly or a new file is created). It does not explicitly name alternative tools, but the use case for versioning is clearly implied, making it easy for an agent to select this over a plain upload.
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?
The description adds valuable behavioral details beyond the annotations, such as the exact return fields (login state, token expiry, user name/email) and that the data comes from a cached ID token. It also explains the 'pending' state, which is not captured in annotations. No contradictions with readOnlyHint or idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the main purpose, and every sentence adds meaningful information. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and a rich output schema, the description fully covers when and why to use the tool, including return values and edge cases like pending logins. It is complete for a status-checking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers all inputs. Per the baseline, a score of 4 is appropriate since there is nothing to describe beyond the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the user's sign-in status for Trimble Connect. It uses a specific verb ('check') and identifies the resource (authentication state). It is distinguished from sibling tools like tc_login and tc_login_cancel by focusing on status rather than initiating or canceling login.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly specifies when to call this tool: first if any other tool returns an authentication error, and after a tc_login call with 'pending': true. It also clarifies the meaning of 'login_in_progress' for pending browser sign-ins, providing clear context for use.
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?
Although the annotation destructiveHint=true already flags destructive behavior, the description adds critical detail: 'Everything not listed in acl loses its explicit permission.' It also discloses the safety gate confirm=true, providing context 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and safety guidance, then presents a terse list of arguments. While the Arg section repeats parameter names from the schema, it is justified given the schema lacks descriptions and is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a complex tool with 6 parameters and an output schema: it covers prerequisites, destructive semantics, parameter options, and provides an example return payload. An output schema exists, but the description still adds value by showing the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates fully by explaining every parameter inline, including acl's expected format ({"READ": [ids], ...}) and noting defaults for item_type and inheritance. This adds semantic meaning absent from the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'REPLACE the whole ACL of a folder or file (advanced)' providing a specific verb and resource, and explicitly contrasts with sibling tools tc_grant_permissions and tc_remove_permissions, making its unique purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Prefer tc_grant_permissions / tc_remove_permissions, which merge safely,' offering a clear alternative and indicating when not to use this tool. It also states prerequisites (TC_ENABLE_WRITE=1 and confirm=true), giving concrete usage conditions.
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 annotations (readOnly, idempotent, non-destructive), the description adds important behavioral details: pagination is fetched fully 'up to a safety cap', project_id routes to a specific region, and omitting it defaults to the master server. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, usage guidance, arg explanations, and return behavior. Every sentence provides unique value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as an advanced API escape hatch with no output schema, the description covers all necessary aspects: path construction, optional routing, params, return format, and pagination behavior. It is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining each parameter: path with format examples and restriction ('Must not include a scheme/host'), project_id with routing behavior, and params as a 'flat string dict'. This adds meaning far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'perform a raw GET on the Trimble Connect Core API (v2) and return the raw JSON', providing a specific verb, resource, and result. It effectively distinguishes itself from dedicated sibling tools by labeling itself an 'escape hatch' and providing example endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use when no dedicated tool covers an endpoint' with concrete examples, and 'Read-only — for writes use the dedicated tools, or tc_api_write.' This clearly states when to use and explicitly names the alternative write tool.
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?
The description adds substantial behavioral context beyond the annotations: it explains the safety gate (confirm=true), the regional routing behavior (project_id recommended, otherwise master/North America), and the exact return shape ('raw JSON response or {"status": 204}'). This complements the destructiveHint and readOnlyHint annotations without 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by tight arg definitions and return behavior. Every sentence earns its place; there is no fluff or repetition of schema fields, and the formatting makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explains the return value, prerequisites, routing behavior, and parameter semantics. For a complex, dangerous escape-hatch tool with six parameters, this is fully sufficient 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must carry the full burden, and it does. Every parameter is explained with meaningful detail: method values, path constraints ('No scheme/host'), confirm's role as a safety gate, project_id's routing effect, params as query parameters, and body as optional JSON.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an advanced escape hatch for raw POST/PATCH/PUT/DELETE calls to the Core API v2, with a specific scope: 'Only for endpoints with no dedicated tool'. This distinguishes it from sibling tools like tc_api_get and the many dedicated write tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('Only for endpoints with no dedicated tool'), providing examples such as todos, views, releases, and attributes. It also communicates critical prerequisites: 'Requires TC_ENABLE_WRITE=1 AND confirm=true', which guides the agent on safe and appropriate invocation.
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?
Annotations already declare readOnly and idempotent hints; description adds rich context: recursive walking, breadth-limits by max_depth and max_entries, truncation reporting, and what the output contains (folder IDs, file sizes, dates). 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: opening verb phrase, then brief behavioral summary, then Args/Returns sections. Each sentence carries necessary information and there is no redundancy. The length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is self-contained: explains purpose, back-off behavior, return format, and truncation. With an output schema present, it could have omitted return details, but including them adds value. Sibling tools are also referenced for further actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description compensates fully with an Args section explaining each parameter, including defaults (folder_id default root, max_depth default 3, max_entries default 400) and constraints (1-6 depth). This goes beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb+resource: 'Render a compact text tree of the project's folder structure.' It clearly distinguishes itself from siblings like tc_list_folder by emphasizing the tree view and even references tc_list_folder for drilling in.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'ideal for a quick overview of a CDE structure before drilling in.' Also notes how to drill into subtrees via tc_list_folder / tc_folder_tree, giving an alternative and follow-on usage.
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?
The description goes far beyond the annotations, detailing the non-blocking behavior, background listener timeout (10 minutes), token caching and auto-refresh, the 'pending' return state, and browser launching behavior. It adds crucial operational context that annotations alone (readOnlyHint, idempotentHint) do not convey, and it is consistent with them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (main explanation, 'Args', 'Returns') and is front-loaded with the core purpose. Despite its length, every sentence serves a functional purpose—explaining behavior, parameters, or user instructions—with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two simple parameters and no output schema shown, the description covers everything: the OAuth flow, callback mechanism, caching, pending behavior, user guidance, parameter semantics, and return contract. It also integrates well with sibling tools (tc_auth_status, tc_login_cancel), making the context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining both parameters: wait_seconds (default 90, controls how long before returning pending) and open_browser (false returns auth_url without launching). It also documents the return variants, covering what the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource: 'Sign in to Trimble Connect via the browser (OAuth2 + PKCE).' It fully distinguishes the tool from its siblings by framing it as the initial authentication step, explicitly referencing tc_auth_status as the follow-up for pending logins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use ('only needed the first time or after the session fully expires'), warns against repeated calls ('Do NOT immediately call tc_login again'), and prescribes the correct alternative ('call tc_auth_status to confirm'). This is exemplary usage guidance.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/nhantruong96/trimble-connect-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server