forbiz_searchSearch Forbiz CRM records by keyword across actions, evidence, people, organizations, projects, outreach, and decisions to retrieve relevant context.
Full-text search across actions, evidence, people, organizations, projects, outreach and decisions (GET /search). To resume a commitment by its key, use forbiz_commit with the same commitmentKey instead: the 409 returns it.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search terms | |
| type | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the HTTP method and the cross-tool 409 behavior, but says nothing about result shape, pagination, or result ordering for a broad search.
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, with the core scope front-loaded in sentence one. The second sentence spends its words on a sibling tool's behavior rather than this tool, which is useful routing but slightly off-center.
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 read-only search with annotations covering the safety profile and no output schema, the description covers scope, endpoint, and the key routing trap. It stops short of return-format or result-limit context, which an agent would otherwise want since no output schema exists.
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 50%: 'q' is minimally described as 'Search terms' and the 'type' enum has no description at all. The prose enumeration of categories loosely maps to the enum values, giving some implicit help, but it never explains the 'type' filter (or values like 'all'/'context'), so it only partially compensates for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (full-text search) and enumerates the exact resource set it spans (actions, evidence, people, organizations, projects, outreach, decisions), so an agent knows the search corpus without opening the schema. The endpoint (GET /search) further pins it down.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit alternative for one case: resuming a commitment by key should go through forbiz_commit, and it explains the 409 signal. It does not distinguish this from content-specific siblings like forbiz_find_evidence or forbiz_get_action, so coverage of alternatives is partial rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.