Loading ToolBench
Agentforce Agent Creator - create agentforce agents through AI-driven discovery and metadata generation
This server has severe gaps in definition quality. Both tools have descriptions that appear to be prompt injections rather than tool specifications. The get_agent_requirements tool has a 2,500+ character description containing the actual LLM prompt (a 'Prompt: Discovery Conversation for Agent Requirements' with conversation guides, rules, and examples), which is not a tool definition. The generate_agent_metadata tool description is truncated and incomplete. Neither tool has documented output schemas. Parameter descriptions are minimal. Input schemas are present but sparse. The server appears to conflate LLM system prompts with MCP tool definitions, which is a fundamental architectural misunderstanding.
Create a description of an AI Agent, generating sample utterances, and convert a list of topics into a specific JSON format. The description and sample utterances should be grounded in the context of the conversation. Converts Topics, description, scope, instructions and actions to JSON format following specific naming and formatting rules.
An AI assistant that helps gather requirements for an autonomous agent implementation through conversation. Have a friendly, open conversation with the user to understand what kind of AI assistant they need. Gathers clear requirements including business challenges, desired capabilities, and how success should be measured.
Tool descriptions are LLM system prompts, not tool specifications. The get_agent_requirements description is a 2,500+ character prompt injection containing conversation guides, example dialogues, and Salesforce-specific instructions. This should be extracted to the MCP server's initialization context or separate prompt resource, not embedded as a tool description.
Missing output schemas. Neither tool documents what it returns. The rubric requires documented return types (100% of A+ tools have them). Without output schemas, LLMs cannot plan follow-up calls or extract required fields.
generate_agent_metadata description is truncated. The visible source code cuts off mid-description ('Create a description of an AI Agent, generating sample utterances, and conv'). Cannot assess completeness, but truncation itself suggests inadequate definition.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 33 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Parameter descriptions are minimal. The get_agent_requirements tool has 'List of requirements gathered from the conversation' and 'Unique identifier for tracking the conversation and requirements', these are terse and do not provide LLM-optimized guidance. No constraints (e.g., max array size, format of conversation_id) are documented.
No error handling guidance. Descriptions do not explain what errors can occur, how to recover, or what the LLM should do if a call fails. This violates the recovery-guide pattern.
Credentials leaked in server initialization. The server.py file loads SALESFORCE_USERNAME and SALESFORCE_PASSWORD from environment variables and stores them in a SalesforceCredentials object accessible via server.credentials. This violates the secret-injection pattern, secrets should never be accessible to tools or logged in traces.
No permission gates. The tools directly invoke Salesforce operations via imported utils (agent_requirements, deploy_agent) with server-level credentials, bypassing any per-user or per-agent authorization checks.
Stateful server design. The server maintains dictionaries for agents, conversations, and deployments (server.agents, server.conversations, server.deployments) as in-memory state. This violates stateless request handling in the current MCP spec (2026-07-28). Each request must be self-contained.