Skip to main content
Glama
TylerIlunga

Procore MCP Server

Create Action Plan Item Assignee Signature

create_action_plan_item_assignee_signature

Create a signature for an action plan item assignee. Provide project and assignee IDs, along with an attachment or base64 PNG string, to generate and return the new signature record.

Instructions

Create a single Action Plan Item Assignee Signature. Note that only one of attachment or attachment_string may be passed when creating a signature, not both. Pass the record's fields as top-level arguments — they are nested under "signature" in the request payload for you. project_id defaults to the value set by procore_set_config when omitted, and plan_item_assignee_id must identify an existing parent record — resolve it with the matching list tool first. Creates the action plan item assignee signature and returns it with its new id (HTTP 201); calling it again creates another record. Failures come back as an error payload carrying the HTTP status — commonly 401 when the token has expired, 403 without tool permission, and 404 when an id does not resolve. Required parameters: project_id, plan_item_assignee_id, attachment, attachment_string. Procore API: Project Management > Action Plans. Endpoint: POST /rest/v1.0/projects/{project_id}/action_plans/plan_item_assignees/{plan_item_assignee_id}/signature

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
attachmentYesJSON request body field — attachment representing the Signature. To upload an attachment you must upload the entire payload as `multipart/form-data` content-type with the `attachment` file.
project_idYesURL path parameter — unique identifier for the project.
attachment_stringYesJSON request body field — base64 encoded string representing PNG image of signature
plan_item_assignee_idYesURL path parameter — action Plan Item Assignee ID
Behavior5/5

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

The description richly discloses behavioral traits beyond annotations: it mentions non-idempotency ('calling it again creates another record'), success response format (HTTP 201 with new id), defaulting behavior for project_id, and common failure modes (401, 403, 404). These details significantly enhance transparency without contradicting 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/5

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

The description is dense but well-structured, covering purpose, constraints, defaults, error handling, and endpoint reference. The sentence listing required parameters is redundant with the schema, and the overall length is justified given the tool's complexity and the need to convey multiple behaviors.

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

Completeness4/5

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

The description provides a comprehensive picture: what the tool creates, prerequisites (resolving parent record), parameter constraints, response behavior, and error scenarios. The note that project_id defaults when omitted conflicts with the schema's required flag, which is a minor inconsistency in an otherwise thorough description.

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

Parameters4/5

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

Schema descriptions already cover 100% of parameters, providing a baseline. The description adds critical semantic value by highlighting the mutual exclusivity of attachment and attachment_string, explaining that fields are passed as top-level arguments despite being nested in the payload, and noting project_id's default. The required-parameter list is redundant but does not detract from the added semantics.

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

Purpose5/5

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

The description clearly states the tool's purpose with a specific verb ('Create') and a fully qualified resource ('Action Plan Item Assignee Signature'), distinguishing it from sibling tools like delete, show, or other signature creation tools. It also adds detail about the payload structure and constraints, 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/5

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

The description provides clear context: it instructs the agent to resolve plan_item_assignee_id using a matching list tool first and warns about non-idempotency. However, it does not explicitly name alternative tools (e.g., approver or receiver signatures) or state when not to use this tool, so it lacks explicit exclusions.

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

Install Server

Other Tools

Latest Blog Posts

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/TylerIlunga/procore-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server