Tendeck: free real estate CRM

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

No annotations are provided, so the description carries the full burden. It discloses key workflow behavior beyond the schema: entries include capability summaries and connection instructions, and the not-live path requires an honesty statement, a workaround, and a follow-up call to connector_request. It stops short of stating whether results are paginated or complete.

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?

Front-loaded with what the tool returns, then the trigger conditions, then the fallback procedure. The example tool names earn their space by anchoring intent recognition. Slightly dense mid-sentence but no filler.

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?

The description explains what each catalog entry contains, so the absence of an output schema is acceptable, and the no-annotation read-only nature is self-evident for a catalog. The one real gap is the undocumented category filter, which matters given zero schema coverage.

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

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

Schema description coverage is 0% and the description must compensate for two enum parameters. It indirectly maps the status values ('live', 'next being built', 'planned') but never clarifies 'researching', and the category parameter is not mentioned at all — an agent must guess what each category means.

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

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

Names a specific resource (the connector catalog) and enumerates its contents — live, next, planned, each with what it gives the agent and how to connect. Easily distinguished from siblings like describe_product or tendeck_help. It does not explicitly distinguish itself from list_addons, which is the one plausible confusion point.

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?

Explicit trigger ('does Tendeck work with X?' or naming a tool like dotloop, SkySlope, Zillow), explicit handling for the negative case (be honest, give the 'today' workaround), and an explicit alternative (connector_request) for recording interest. Nothing is left to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the content scope but does not state that the operation is read-only, whether it has side effects, how results are returned, or any access constraints.

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

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

The description is a single front-loaded sentence with no wasted wording. It efficiently states the core content and scope.

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

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

For a simple tool with no required parameters and no output schema, the description gives enough content scope to call it correctly. It could be improved by clarifying how it differs from overlapping siblings, but the core purpose and returned topics are clear.

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

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

Schema description coverage is 100%, and the single optional product parameter is already documented as an enum with descriptions. The description adds useful mapping by naming P1 as brokerage recruiting CRM and P2 as agent CRM, but it does not add syntax or behavior beyond that.

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

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

The description states a specific resource and content: a plain-language description of the two Nuvidian products, including free features and product boundaries. It names P1 and P2 clearly, but it does not distinguish this tool from sibling tools like get_free_limits or tendeck_help, which may cover overlapping information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives such as get_free_limits, tendeck_help, or connectors_catalog. The description implies it is for product understanding, but it does not state exclusions or routing conditions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the scope of returned information and explains the absence of AI quotas, but it does not explicitly state that the operation is read-only, whether authentication is required, or what the response shape looks like.

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

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

The description is a single front-loaded sentence with no wasted preamble. The parenthetical examples are dense but directly support the purpose by specifying what the free limits contain for P1 and P2.

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

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

For a zero-parameter tool with no output schema and no annotations, the description gives enough substance for selection: it states the resource, the product split, and concrete examples of the returned limits. It could still be more complete by explicitly noting read-only behavior or clarifying the full set of products covered.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The empty schema is consistent with the description, which correctly presents this as a parameterless informational getter.

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

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

The description states a specific resource and scope: free inclusions per product, with concrete P1 and P2 details. It is clearly more than a restatement of the name, but it does not explicitly differentiate this tool from siblings such as describe_product or list_addons.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance, no prerequisites, and no routing to alternatives. The intended use can be inferred from the content, but the description does not say when an agent should choose this tool over related catalog or product-description tools.

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

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

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavior about the returned numbers — unit pricing in cents, and explicitly not cost or margin — but says nothing about pagination, whether all add-ons are always returned, or read-only/safety characteristics.

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

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

Two short sentences, zero filler, with the most important disambiguation ('prices only') front-loaded. Nothing to cut.

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

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

For a zero-required-param listing tool with no output schema, the description gives enough to call it and interpret the numbers (cents, unit price, not cost). It stops short of describing what else identifies each add-on in the payload, which is the only remaining gap.

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

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

Schema coverage is 100% and the single 'product' enum is fully documented in the schema (including 'both'), so the schema does the work. The description adds no meaning about filtering semantics beyond what the enum already states; baseline 3 applies.

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

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

The description names the resource precisely (paid add-ons) and the fields returned (unit, price in cents), so an agent knows this is the pricing catalogue endpoint. It lacks an explicit verb and does not name a contrasting sibling, but 'prices only — no costs, no margins' does separate it from any cost/margin tooling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent must infer 'call this to see add-on pricing'. The clause 'Prices only — no costs, no margins' is a useful scope exclusion that steers the agent away from expecting margin data, but no when-to-use condition or alternative (e.g. connectors_catalog, get_free_limits) is named.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that the data is unmistakably fake, that nothing is written, and that nobody is contacted. It also specifies how the output should be presented, including card order, score, and the plain-English 'why' line.

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

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

The description is front-loaded with the core purpose and usage trigger, then adds only operationally useful display instructions and safety notes. Every sentence contributes something an agent needs.

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

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

For a no-annotation, no-output-schema tool, the description is complete: it explains what the sample contains, how fake the data is, how to present the results, and what side effects do not occur. An agent has enough context to call and present it correctly.

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

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

There is only one parameter, n, and the schema already documents its range and default with 100% coverage. The description adds no parameter-specific meaning beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource: showing a sample of Nuvidian P1's 'Today's 10' deck. It also scopes the content as fictional Florida agents deliberately built as a pre-signup demo, which implicitly distinguishes it from real-practice siblings like p2_practice_today.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit trigger phrases: call it when someone asks 'what is P1?' or 'show me'. It does not name alternatives such as describe_product or p2_practice_today, so the when-not/alternative routing is implied rather than stated.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it states the data is fictional, nothing is written, nobody is contacted, the cards should be read in order with their 'why' line, and a note explains the people are fake and how to start a workspace.

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

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

The description is somewhat long but front-loads the core purpose and then adds useful invocation and output-reading guidance. Most sentences earn their place by explaining what the agent will see and how to present it.

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

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

Given the tool has no parameters, no annotations, and no output schema, the description is complete enough: it explains the fictional sample, the card types, how to read them aloud, and the closing note. An agent can call and present the result correctly without additional structured metadata.

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

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

There are zero parameters, so parameter semantics are not applicable; baseline is 4. The description correctly does not invent parameter behavior and instead describes the output content.

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

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

The description uses a specific verb and resource: it shows a fictional sample of P2's Today's 10 to let a human preview the product. It clearly distinguishes this sample/demo behavior from real workspace actions and from sibling tools like describe_product or p1_practice_deck by focusing on fictional cards and the pre-signup preview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear triggering contexts, such as when someone asks 'what is P2?' or 'show me'. It does not explicitly name alternatives or when-not-to-use cases, but the demo/preview context is strong and unambiguous.

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

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

With no annotations, the description carries the behavioral burden and discloses key traits: creates a pending workspace, sends a code to email or US phone, is idempotent on idem_key, and gates on terms acceptance. It still omits failure behavior and response details, but the core mutation and idempotency semantics are present.

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

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

The description is compact and front-loads the signup action, then the code flow, then the terms requirement. The "FIRST" instruction appears last, which is slightly awkward, but every sentence adds needed flow information.

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

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

For a complex signup tool with no output schema and no annotations, the description covers the essential workflow, terms gating, idempotency, and the next tool to call. It lacks return-value and error-case details, but the operational essentials are present.

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 schema already documents the parameters. The description adds useful semantics beyond the schema: email is preferred over phone, idem_key makes retries safe, and accept_terms must only be true after explicit user acceptance.

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

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

The description uses a specific verb and resource: "create a pending workspace and send a 6-digit code." It clearly frames this as the signup step and names verify_phone as the next action, so an agent can distinguish it from sibling tools like verify_phone or describe_product.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit sequence: ask for the code, then call verify_phone. It also states the prerequisite of showing Terms of Service and Privacy Notice and passing accept_terms: true only after acceptance, which is unambiguous when-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only knowledge lookup with no side effects, but never states the return format (free-text answer vs. article link), whether it needs authentication, or how it behaves when no answer exists — meaningful gaps for a tool the agent is told to call as a last resort before admitting ignorance.

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 tight sentences: the capability and its scope come first, followed immediately by the escalation instruction. Every clause earns its place, and the parenthetical list is compact rather than padded.

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

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

For a one-optional-parameter, no-output-schema tool this is nearly sufficient — the agent knows what to send and when. The remaining gap is what comes back and how to interpret an empty or low-confidence answer, which matters because the tool is positioned as the fallback before declaring ignorance.

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% and the single optional `topic` property is already documented with an example, so the schema does the work. The description's topic enumeration reinforces what belongs in that field but adds no syntax, phrasing, or granularity guidance beyond the schema text.

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

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

States a specific verb and resource ("Answer any how-to or support question") and enumerates the covered domains (sign-in, password, billing, connecting ChatGPT/Claude, importing, texting, privacy), so an agent knows the tool is a support-knowledge lookup. It does not explicitly contrast with siblings like describe_product or get_free_limits, which could plausibly answer adjacent questions such as pricing or product capability.

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?

"Call this BEFORE telling the user you don't know" is an explicit, actionable trigger that tells the agent exactly when to reach for this tool as a fallback. However, it offers no exclusions or routing guidance relative to the sibling tools, leaving overlap with describe_product and get_free_limits unresolved.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the key side effect (workspace activation) and return value (session token), but does not describe invalid/expired code handling, whether the code is consumed, or other operational constraints.

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

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

A single front-loaded sentence with no wasted words. It leads with the action and outcome efficiently.

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

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

For a simple two-parameter verification step, the description covers the action, side effect, and returned session token. It could be richer about failure modes, but it is sufficient to invoke the tool correctly given the detailed schema.

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

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

Schema coverage is 100%, so both parameters are already documented. The description restates the code source and 6-digit format but does not add meaningful semantics beyond the schema.

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

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

States a specific action: checking a 6-digit code to finish signup, activate the workspace, and return a session token. The outcome is clear, though it does not explicitly differentiate itself from the sibling start_workspace tool beyond the phrase 'Finish signup.'

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?

'Finish signup' gives a clear usage context, and the schema links tenant_id to start_workspace. It does not explicitly state prerequisites or exclusions, but the intended point in the flow is understandable.

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