suitedash_get_companyOne CRM company by UID or exact name, with primary contact, category, tags, address and custom fields. GET /company/{identifier}.
| Name | Required | Description | Default |
|---|---|---|---|
| meta | No | Also return the field schema (meta object) for each record. Rarely needed: use the *_fields tool instead. | |
| identifier | Yes | The company's UID or name. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so safety is covered. The description adds genuinely useful behavior: it discloses the returned field set (which matters since there is no output schema) and signals that name matching is exact rather than fuzzy. Not-found/ambiguity behavior is not covered, keeping it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact clauses, front-loaded with the resource and scope before the returned fields. The trailing REST endpoint is mildly redundant for an agent but cheap and cheaply placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A simple two-parameter read tool with full schema coverage and annotations carrying the safety profile; the description fills the one real gap (returned content, absent an output schema). Missing only edge-case behavior such as no-match or duplicate-name handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description earns above baseline by clarifying the matching semantics of 'identifier' as an exact name (the schema only says 'UID or name'), which materially affects how an agent should construct the call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Get company') and narrows scope to a single record retrieved by UID or exact name. It also enumerates the payload (primary contact, category, tags, address, custom fields), which lets an agent distinguish it from suitedash_list_companies. It does not explicitly name the sibling it supersedes, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'one company by UID or exact name' phrasing implies a single-record lookup, so the when-to-use case is inferable, but no alternative is named (list_companies for browsing, get_company_fields for schema). The only explicit routing between tools lives in the schema's meta description, not in the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.